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1.  SCOPE 


1.1.  Identification.  This  Software  System  User’s  Manual  (SSLTM)  establishes  the  operat¬ 
ing  and  user  procedures  for  the  computer  software  configuration  item  (CSCI)  identified 
as  the  Integration  of  Very  High  Speed  Integrated  Circuit  (VHSIC)  System  Functional 
Design  and  Design  for  Testability  tools,  to  be  known  as  the  Test  Engineer’s  Assistant 
(TEA)  system. 

1.2.  Purpose.  The  Architecture  Design  and  Assessment  System  (ADAS®)  provides  a 
graphic  schematic  capture  capability  to  VHSIC  designers.  TEA  provides  a  design 
automation  system  for  the  incorporation  of  design  for  test  (DFT)  and  built-in  test 
(BIT)  techniques  into  VHSIC  digital  hardware  which  is  described  by  using  ADAS  and 
VHSIC  Hardware  Description  Language  (VHDL).  TEA  provides  the  methodology  and 
the  tools  for  evaluating  proposed  designs  for  hard-to-test  constructs,  for  recommending 
alternative  constructs,  and  for  identifying  hierarchical  BIT  techniques  to  increase  the 
overall  testability  of  a  hardware  system.  TEA  is  designed  to  aid  users  at  the  board, 
subsystem,  and  system  levels.  TEA  estimates  the  costs  associated  with  the  BIT  tech¬ 
niques  to  allow  the  designer  to  make  informed  choices  about  BIT  incorporation.  A 
library  of  reusable  BIT  modules  supports  TEA  and  enables  the  designer  to  simulate 
the  testable  system  in  VHDL.  ADAS  provides  the  interface  to  VHDL  from  the  graphic 
connectivity  schematic. 

This  document  should  be  used  in  conjunction  with  the  Reference  Manual  for  the  Test 
Engineer’s  Assistant  System.  The  reference  manual  will  help  the  user  prepare  for  use 
of  the  TEA  tools;  this  user’s  manual  will  aid  in  the  mechanics  of  the  use  of  the  tools; 
the  reference  manual  will  be  useful  in  the  analysis  of  the  outputs  of  the  tools  and  in 
identifying  the  direction  that  the  user  should  take  depending  on  that  output. 

The  main  purpose  of  this  document  is  to  present  TEA  from  the  user’s  point  of  view. 

1.3.  Introduction.  This  SSUM  specifies  the  computer  operation  procedures  for  the 
VAXstation  II/GPX  (Section  3)  and  the  user  specifics  for  the  TEA  system  (Section  4). 


ADAS  is  a  registered  trademark  of  Research  Triangle  Institute. 
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2.  REFERENCED  DOCUMENTS 


The  following  documents  are  considered  useful  to  the  user  of  TEA: 

•  TEA  Reference  Manual 

•  ADAS  User  Manual  -  Version  2.3  or  later 

•  TEA  Installation  Guide  -  Version  PROTO. TYPE/Contract 

•  Software  User's  Manual  for  the  VHSIC  Silicon  Compiler  System 

•  Software  User’s  Manual  for  the  ADAS/VHDL  System 

These  documents  are  available  by  contacting  the  Research  Triangle  Institute  (RTI) 
ADAS  marketing  coordinator  at 

Research  Triangle  Institute 
Center  for  Digital  Systems  Research 
P.  O.  Box  12194 

Research  Triangle  Park,  NC  27709 
Phone:  (919)  541-7436 

•  MicroVMS  Workstation  User’s  Guide,  May  1986 

•  MicroVMS  Workstation  Software  Installation  Guide,  November  1986 

•  VAXstation  II/GPX  Hardware  Information  Manual,  1986 

These  documents  are  available  by  writing  to 

SSG  Publications  ZK1-3/J35 
Digital  Equipment  Corporation 
110  Spit  Brook  Road 
Nashua,  NH  03062-2698 
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3.  COMPUTER  SYSTEM  OPERATION 


Separate  installation  instructions  are  provided  with  the  TEA  distribution  tape. 

This  section  will  provide  pointers  to  the  documentation  provided  with  the  VAXstation 
II/GPX  (TEA  workstation)  by  Digital  Equipment  Corporation  rather  than  try  to 
rewrite  this  information.  Information  concerning  computer  system  preparation  is 
found  in  the  hardware  manual.  Operating  procedures  are  found  in  the  user’s  guide, 
and  software  installation  and  testing  procedures  are  found  in  the  software  installation 
guide.  The  following  paragraphs  will  summarize  the  information  found  within  these 
three  information  sources. 

The  Digital  Equipment  Corporation’s  VAXstation  II/GPX  Hardware  Information 
Manual  (dated  1986)  is  divided  into  six  parts: 

Part  I:  Base  System  Installation  —  describes  how  to  unpack,  install,  and  test  the  VAX¬ 
station  II/GPX, 

Part  II:  Operation  —  describes  the  operation  of  the  VAXstation  II/GPX. 

Part  III:  Option  Installation  —  describes  the  hardware  options  for  the  VAXstation 
II/GPX  and  gives  installation  information  where  applicable. 

Part  Troubleshooting  —  describes  how  to  isolate  a  problem  and  decide  what  to  do 
next. 

Part  V:  Appendixes  —  provides  VAXstation  II/GPX  system  specifications.  Appendix 
B  lists  related  documents. 

Part  VI:  Glossary  —  defines  computer  terms  that  are  italicized  at  first  use  in  the  text 
as  well  as  other  common  computer  terms. 

The  Digital  Equipment  Corporation’s  MicroVMS  Workstation  User’s  Guide  (dated  May 
1986)  is  divided  into  three  chapters  and  four  appendices: 

Chapter  1:  Getting  Started  —  provides  an  overview  of  the  workstation  functions  and 
introduces  some  of  the  terminology  used  in  the  guide. 

Chapter  2:  The  Workstation  Options  Menu  —  describes  the  functions  of  the  Worksta¬ 
tion  Options  menu. 

Chapter  3:  Using  Windows  —  explains  window-management  tasks  such  as  creating, 
moving,  and  resizing  windows. 

Appendix  A:  VAXstation  Support  for  Tektronix  4010/4014  Terminals  —  describes 
V.XXstation  support  for  Tektronix  4010/4014  terminal  emulation.  TEA  users  will  not 
specifically  need  this  information. 

Appendix  B:  Additional  Features  of  the  VT220  Terminal  Emulator  —  provides  addi¬ 
tional  setup  information  for  VT220  terminal  emulation. 

Appendix  C:  Compose  Sequences  —  provides  information  on  compose-character 
sequences,  including  tables  for  both  the  multinational  and  the  national  character  sets. 
TEA  users  will  not  specifically  need  this  information. 
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Appendix  D:  National  Keyboards  for  VT220  Emulation  —  illustrates  the  keyboard 
character  configurations  for  the  various  languages  supported  by  the  VAXstation.  TEA 
users  will  not  specifically  need  this  information. 

The  Digital  Equipment  Corporation’s  MicroVMS  Workstation  Software  Installation 
Guide  (dated  November  1986)  is  divided  into  three  chapters  and  one  appendix: 

Chapter  1;  Installing  on  a  VAXstation  I,  VAXstation  II,  or  VAXstation  II/GPX  — 
describes  how  to  install  workstation  software  on  the  VAXstations. 

Chapter  2:  Installing  on  a  Local  Area  VAXcluster  —  describes  how  to  install  worksta¬ 
tion  software  on  the  VAXcluster. 

Chapter  3:  VAXstation  Management  and  Tuning  —  provides  information  on  tuning 
the  workstation  software. 

Appendix  A:  Files  Installed  by  MicroVMS  Workstation  Software  —  lists  files  installed 
by  the  workstation  software. 
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4.  ESrSTRUCTIONS  FOR  USE  —  TEA 


This  section  has  been  labeled  as  Chapter  Z  —  TEA:  The  Test  Engineer’s  Assistant  and 
could  be  added  as  a  chapter  in  the  user’s  ADAS  documentation. 
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CHAPTER  Z  —  TEA;  THE  TEST  ENGINEER’S  ASSISTANT 


INTRODUCTION 


The  Test  Engineer’s  Assistant  (TEA)  is  a  set  of  software  toois  and  utilities  that  help  a 
digital  hardware  designer  design  testable  systems.  These  software  tools  and  utilities 
have  been  integrated  into  the  ADAS  user  interface  and  have  been  combined  with 
several  existing  ADAS  functions  to  provide  all  that  is  necessary  to  accomplish  the  goal. 
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ASSUMPTIONS  ABOUT  USER  KNOWLEDGE 


TEA  makes  some  assumptions  about  the  user’s  knowledge.  The  tool  is  designed  to  be 
used  by  a  system  design  team  with  little  or  no  testability  experience.  Such  a  team 
might  include  system  specialists  and/or  hardware  systems  designers.  Thus,  a  familiar¬ 
ity  with  hardware  design  terminology  is  assumed. 

Although  TEA  operates  on  the  assumption  that  the  user  is  not  a  testability  engineer, 
it  does  assume  that  the  basic  terminology  of  testability  is  known.  The  following  list 
describes  some  of  the  basic  testability  terms  with  which  the  user  must  be  familiar. 
Consult  the  TEA  Reference  Manual  for  a  complete  description  of  these  and  other  test¬ 
ing  terms. 

a.  ambiguity  group  (AG), 

b.  built-in  test  (BIT), 

c.  BIT  techniques, 

d.  design  for  testability  (DFT), 

e.  deterministic  and  pseudorandom  test  patterns, 

f.  mean  time  to  test, 

g.  test  pattern  application,  and 

h.  test  pattern  generation. 

The  designer  must  have  experience  using  ADAS  to  capture  a  design. 
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TEA  RESTRICTIONS  AND  LIMITATIONS 


TEA  only  executes  on  a  non-empty  ADAS  hardware  graph  data  base. 

Window  scaling  minimum  of  6  locations  by  6  locations;  maximum  of  600  lo¬ 
cations  by  600  locations. 

Maximum  of  100  user-defined  macros  active  at  once  during  a  TEA  session. 

Several  colors  are  available  for  graph  nodes  and  arcs.  The  ADAS  User 
Manual,  Version  2.3  or  later,  lists  the  colors  in  the  ADAS  palette. 


TEA:  The  Test  Engineer’s  Assistant,  SSUM 


P 


Z-3 


TEA  MENU  SYSTEM 


The  TEA  menu  system  retains  the  basic  format  of  the  ADAS  graph  editor,  EDIGRAF . 
An  additional  option,  however,  has  been  added  to  better  suit  the  interactive  tools  in 
TEA.  The  TEA  menu  system  allows  one  of  two  types  of  selections  to  be  made  from  a 
menu: 

a.  single  item  selection  or 

b.  multiple  item  selection. 


Single  Selection  Menus 

A  single  select  menu  is  identical  to  the  ADAS  EDIGRAF  menu  selection.  One  entry 
selection  is  allowed  per  menu.  Once  the  selection  has  been  made,  the  graph  editor 
automatically  cycles  to  the  next  level  in  the  menu  system  or  invokes  the  required  tool 
functions. 


Multiple  Selection  Menus 

A  multiple  select  menu  allows  the  user  to  select  multiple  entries  in  a  menu.  Each 
selected  item  in  the  menu  is  highlighted  to  distinguish  between  selected  and 
unselected  items.  A  multiple  select  menu  is  identified  by  the  presence  of  the  %done 
option  which  is  always  located  at  the  top  of  a  multiple  select  menu.  The  menu 
remains  displayed  until  the  user  has  selected  the  %done  option.  Once  an  item  has 
been  selected  on  the  menu,  the  item  may  be  selected  again  to  unselect  that  item  from 
the  current  menu.  In  some  multiple  select  menus,  an  %bII  option  is  available  which 
automatically  selects  all  menu  items  in  the  current  menu.  The  %aill  option  requires 
that  %done  be  selected  to  indicate  that  all  highlighted  menu  items  are  to  be  used  as 
input.  The  user  is  always  reprompted  after  making  a  selection  (other  than  %done) 
from  a  multiple  select  menu. 

Figures  1  and  2  show  typical  single  select  and  multiple  select  menus  used  in  the  TEA 
tools. 
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TEA  MENU  SYSTEM,  Cent. 


===  menu  === 

%help 
%self 
fllel . hwg 
flle2.hwg 

Compare:  Select  the  comparison  graph: 


Figure  1.  Typical  Single  Select  Menu 


^  ===  menu  === 

%done 

boards 

boards 

%help 

board4 

boards 

JSall 

boards 

board 1 

boards 

board2 

board? 

^  DFT:  Indicate 

the  board (s) 

of  Interest: 

_ > 

Figure  2.  Typical  Multiple  Select  Menu 
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TEA  TOP-LEVEL  MENU 


The  top-level  menu  contains  menu  options  to  access  all  the  TEA  tools  and  utilities  as 
well  as  the  ADAS  functions  available  in  TEA.  Figure  3  shows  the  terminal  display  for 
the  TEA  top-level  menu. 


^  ===  menu 

quit 

brt 

log_flle 

hardcopy 

save 

blt_cost 

window 

script 

edit 

placeblt 

environ 

macro 

move 

compare 

stats 

reload 

dft 

Command^ 

ag_name 

subgraf 

help 

Figure  3.  TEA  Top-Level  Menu 

ADAS  Functions 

a.  edit  —  modify  graph,  node,  arc,  bus,  and  template  attributes, 

b.  environ  —  change  the  display  parameters  for  the  graphics  window, 

c.  hardcopy  —  generate  a  plot  of  the  graphics  display  on  a  hardcopy  device, 

d.  macro  —  a  single  name  representing  commonly  used  command  sequences, 

e.  move  —  relocate  an  arc,  bus  junction,  node,  or  block  of  graph  components, 

f.  quit  —  exit  TEA, 

g.  reload  —  reload  the  design  graph  from  the  data  base  files, 

h.  save  —  save  data  base  to  disk, 

i.  script  —  execute  a  predefined  set  of  menu  option  commands, 

j.  stats  —  display  individual  node,  arc  and  bus  statistics, 

k.  subgraf  —  expand  the  subgraf  associated  with  a  particular  node,  and 

l.  window  —  zoom  in  and  out  on  the  current  graphics  display. 
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TEA  Tools 

a.  dft  —  Design  for  Testability  Guideline  Checker, 

b.  brt  —  BIT  Recommendation  Tool, 

c.  bit_cost  —  BIT  Overhead  Summary, 

d.  placebit  —  BIT  Placement  Recommendation,  and 

e.  compare  —  System  Summary. 

TEA  Utilities 

a.  ag_name  —  assign  ambiguity  groups, 

b.  log_file  —  view  and  print  report  files,  and 

c.  help  —  access  on-line  user  support  system. 

Special  Characters 

a.  ?help  —  short  description  of  the  menu  commands, 

b.  .cancel  —  skip  the  command  being  entered  without  executing  it  and  return 
to  the  top-level  menu, 

c.  lescape  —  exit  temporarily  to  the  operating  system  without  leaving  TEA,  and 

d.  *page  —  circulate  to  the  next  menu  page  if  more  items  exist. 
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Existing  ADAS  Functions 

TEA  utilizes  several  ADAS  graph  editor  (EDIGRAF)  functions  in  the  TEA  top-level 
menu.  The  menu  option  names  as  well  as  their  functions  are  identical  to  the  ADAS 
options.  The  unchanged  ADAS  functions  which  are  utilized  by  TEA  are: 

a.  edit, 

b.  environ, 

c.  hardcopy, 

d.  macro, 

e.  move, 

f.  quit, 

g.  reload, 

h.  script, 

i.  stats, 

j.  subgraf,  and 

k.  window. 

A  detailed  description  of  these  options  is  provided  in  Chapter  7  of  this  document. 


Modified  ADAS  Functions 

The  save  ADAS  function  has  been  modified  to  accommodate  TEA-specific  operations; 
however,  the  ADAS  option  name  has  been  retained. 


Save 

The  save  function  provides  a  method  for  the  user  to  write  changes  made  to  the 
“current  view”  data  base  files  to  disk.  The  TEA  save  function  differs  from  the  ADAS 
function  by  allowing  the  user  to  save  a  separate  copy  of  the  current  graph  and  associ¬ 
ated  subgraphs  under  a  new  filename.  By  retaining  previous  versions  of  the  hardware 
graphs,  multiple  combinations  may  be  analyzed  at  a  later  time.  TEA  will  also  allow 
overwriting  of  the  existing  file.  The  save  function  is  invoked  by  selecting  the  save 
option  from  the  TEA  top-level  menu.  Figure  4  shows  the  terminal  display  after  save 
has  been  selected. 
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===  menu  === 

new_copy 

overwrite 


SAVE: 


Save  a  copy  or  overwrite  the  current  graph? 


J 


Figure  4.  save  Function  Menu 


Generating  a  Copy 

A  copy  of  the  “current  view”  hardware  graph  data  base  can  be  made  by  selecting  the 
new_copy  option.  A  new_copy  is  a  copy  of  the  “current  view”  hardware  graph 
stored  to  a  new  file  on  disk.  A  copy  can  be  made  at  anytime  while  at  the  TEA  top- 
level  menu.  There  are  two  types  of  copies  that  can  be  made  when  using  the 
new_copy  option: 

a.  current  —  for  generating  a  copy  of  the  currently  displayed  graph  only  and 

b.  hierarchy  —  for  generating  a  copy  of  the  hierarchy  from  the  current  graph 
up  to  and  including  the  root  level  graph. 

Figure  5  shows  the  terminal  display  for  the  save  new_copy  menu. 
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===  menu  === 

current 

hierarchy 


SAVE  NEW_COPY: 
I  SAVE  NEW_COPY: 


Current  graph  or  hierarchy  as  well? 
Indicate  a  filename  for  the  copied  graph. 
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Figure  5.  save  new_copy  Menu 


Filename  Selection 

If  save  new_copy  current  has  been  selected,  the  user  is  given  the  option  of  indicat¬ 
ing  the  new  filename  of  the  copied  file.  Any  valid  VMS  filename  is  accepted.  If  the 
name  of  an  existing  file  is  used,  a  message  indicating  the  existance  of  that  file  is 
displayed  along  with  a  prompt  to  enter  a  unique  filename.  The  user  is  continually 
reprompted  until  a  unique  filename  is  given  or  the  user  escapes  from  the  nienu  by  typ¬ 
ing  Figure  5  also  shows  the  prompt  for  the  new  filename.  At  the  completion  of 
the  copy,  program  control  is  returned  to  the  TEA  top-level  menu. 
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If  save  new_copy  hierarchy  has  been  selected,  the  names  for  the  new  graphs  are 
automatically  generated.  The  new  filenames  consist  of  the  original  filename  with  a  two 
digit  number  appended.  The  two  digit  number  is  incremented  to  generate  a  unique 
new  filename  each  time  a  copy  is  made.  Hardware  graphs  along  with  the  hardware 
graph  templates  are  copied.  After  all  graphs  in  the  hierarchy  have  been  copied,  pro¬ 
gram  control  is  returned  to  the  TEA  top-level  menu. 


Overwriting  Existing  Graph(s) 

The  overwrite  option  replaces  the  existing  file(s)  on  disk.  There  are  three  options 
available  for  overwriting: 

a.  current  —  for  overwriting  the  currently  displayed  graph, 

b.  hierarchy  —  for  overwriting  the  hierarchy  from  the  current  graph  up  to  the 
root  level  graph,  and 

c.  full  —  for  overwriting  all  graphs  and  subgraphs  connected  to  the  root  level 
graph. 

The  current  and  hierarchy  options  are  identical  to  the  ADAS  options,  however;  the 
full  option  has  been  added  to  TEA  to  allow  copies  of  complete  system  graphs  for  later 
examination  and  comparison.  Figure  6  shows  the  terminal  display  for  the  save 
overwrite  menu. 


===  menu  === 
current 
hierarchy 
full 

SAVE  OVERWRITE:  Overwrite  the  current  graph,  hierarchy  or  all  graphs  ? 
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Figure  6,  save  overwrite  Menu 
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The  following  sections  describe  the  operation  of  TEA.  TEA  supports  the  fo’Hwing 

specific  tools: 

a.  Design  for  Testablity  Guideline  Checker  (dft)  —  identifies  hard-to-test  and 
untestable  structures  and  recommends  alternative  structures, 

b.  BIT  Recommendation  (brt)  —  divides  a  board  into  ambiguity  groups  for  fault 
isolation  testing  and  recommends  a  class  of  BIT  techniques  for  each  ambiguity 
group, 

c.  BIT  Overhead  Summary  (bit_cost)  —  calculates  the  approximate  hardware 
overhead  associated  with  a  particular  BIT  technique, 

d.  BIT  Placement  Recommendation  (placebit)  —  generates  a  new  schematic  of 
the  board  with  a  specific  implementation  of  the  given  technique,  and 

e.  System  Summary  (compare)  —  itemizes  the  incremental  hardware  overhead 
attributed  to  added  testability. 


TEA  supports  the  following  specific  utilities: 

a.  Ambiguity  Group  Names  (ag_name)  —  identifies  user-selected  ambiguity 
groupings, 

b.  Report  Access/Generation  Facility  (log_file)  —  generates  and  provides  view 
capability  of  output  reports  of  the  various  tools,  and 

c.  On-line  User  Support  System  (help)  —  information  to  support  user’s  under¬ 
standing  of  TEA.  This  function  is  called  help  on  the  TEA  top-level  menu. 


The  above  functions  and  utilities  are  detailed  in  the  paragraphs  chat  follow.  TEA  is 
an  EDIGRAF-like  tool  in  that  it  uses  the  ADAS  user  interface,  data  base,  and  graph¬ 
ics.  It  is  invoked  by  the  following  command; 

tea  flle.hwg  [-d  graphlcs_devlce  -s  scrlpt_flle] 

The  graphics  device  may  be  specified  in  an  environment  variable  and  may  include  null. 
It  must  be  initialized  for  TEA  to  execute.  The  script  file  is  optional  and  works  the 
same  as  ADAS  scripts  (see  Chapter  4  for  further  information  about  scripts  and  graph¬ 
ics  devices).  TEA  only  executes  on  a  non-empty  ADAS  hardware  graph  data  base. 
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The  user  interface  is  menu-driven,  allowing  the  user  to  make  selections  with  the  termi¬ 
nal  keyboard  or  to  pick  from  the  graphics  menu  or  graph  itself  by  using  a  mouse  or 
data  pad.  Chapter  4  describes  the  ADAS  user  interface  in  greater  detail.  The  follow¬ 
ing  paragraphs  will  describe  the  TEA  menu  hierarchy  as  it  pertains  to  individual  com¬ 
mands  on  the  top-level  menu  that  are  unique  to  this  tool.  Figure  7  shows  the  terminal 
display  for  the  TEA  top-level  menu. 


===  menu 
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Figure  7.  TEA  Top-Level  Menu 
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Design  For  Testability  Guideline  Checker 


The  Design  for  Testability  Guideline  Checker  (dft)  is  used  to  identify  hard-to-test  and 
untestable  structures  in  a  digital  board  design.  The  design  topology  and  functions  are 
compared  to  predefined  guidelines.  Any  violations  are  reported  to  the  user.  An  ADAS 
hardware  graph  description  is  used  as  input  to  the  dft  tool.  The  connectivity  of  the 
hardware  design  as  well  as  specific  attributes  in  the  ADAS  data  base  are  used  to  deter¬ 
mine  if  any  violations  exist.  The  dft  tool  includes  options  for  graphically  identifying 
several  types  of  structures  as  well  as  an  option  which  explains  the  various  standard 
TEA  guidelines.  The  dft  tool  is  invoked  from  the  TEA  top-level  menu  by  selecting  the 
dft  option. 

The  Design  for  Testability  Guideline  Checker  has  three  subfunctions: 

a.  analyze  —  for  isolating  hard-to-test  and  untestable  constructs  in  a  design  at 
the  board  level  and  recommending  alternative  structures, 

b.  identify  —  for  graphically  identifying  structures  in  a  design,  and 

c.  explain  —  for  on-line  descriptions  of  predefined  guidelines. 


Each  subfunction  may  be  invoked  by  selecting  the  appropriate  command  from  the  dft 
Options  single  select  menu.  Figure  8  shows  the  terminal  display  for  the  dft  options 
menu. 
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===  menu  === 

%help 

analyze 

Identify 

explain 


DFT: 


Select  a  DFT  option  to  be  executed: 


Figure  8.  dft  Options  Menu 
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The  analyze  command  is  the  main  dft  function  which  isolates  predefined  types  of 
untestable  or  hard-to-test  structures  at  the  board  level.  In  addition,  recommendations 
are  given  on  how  to  make  the  design  more  testable  when  a  violation  has  been  detected. 
The  analyze  command  invokes  a  menu  representing  the  types  of  guidelines  the  user 
may  choose  to  invoke  on  a  particular  board  or  set  of  boards.  There  are  two  categories 
of  guidelines  from  which  to  select: 


a.  standard  TEA  guidelines  and 

b.  user-defined  guidelines. 


Either  category  may  be  invoked  by  selecting  the  corresponding  option  from  the  guide¬ 
line  menu.  Figure  9  shows  the  terminal  display  for  the  dft  guideline  menu. 


===  menu  === 
Slhelp 
standard 
user  rules 


Select  the  type  of  rules  to  use: 


Figure  9.  dft  Guideline  Menu 


Standard  TEA  Guidelines 

If  the  standard  TEA  guidelines  option  is  selected,  a  list  of  predefined  guidelines 
appear  on  the  menu.  The  standard  TEA  guidelines  represent  all  the  guidelines  pro¬ 
vided  as  part  of  the  TEA  dft  analyze  guideline  data  base.  These  guidelines  have 
been  divided  into  two  basic  groups: 


a.  aid  test  pattern  generation  and 

b.  aid  test  pattern  application  and  fault  isolation. 

The  user  may  select  any  number  of  these  guidelines  to  be  executed  on  a  specific  board. 
There  are  no  restrictions  on  invoking  test  pattern  generation  or  test  pattern  applica¬ 
tion  guidelines  simultaneously  on  the  same  board.  A  typical  case  would  be  to  invoke 
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all  the  test  pattern  generation  guidelines,  either  individually  or 
proceed  to  the  test  pattern  application  guidelines.  Figure  10 
display  for  the  dft  select  guildeline  menu. 
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Enter  ***  to  view  additional  menu  Items 
DFT:  Select  the  guideline (s)  to  be  executed: 


Figure  10.  dft  Select  Guideline  Menu 


The  user  has  several  options  for  invoking  specific  guidelines.  The  most  basic  option  is 
to  select  a  particular  guideline  from  the  menu.  Since  this  is  a  multiple  selection  menu, 
any  number  of  guidelines  may  be  selected.  If  a  guideline  has  been  selected  it  will  be 
highlighted  on  the  menu  display.  Any  selected  guideline  may  be  deselected  by  select¬ 
ing  the  highlighted  guideline  from  the  menu  again. 

To  simplify  the  selection  of  multiple  guidelines,  three  grouping  options  have  been 
incorporated  into  the  menu  selection.  All  of  the  aid-to-test-pattern  generation  guide¬ 
lines  may  be  selected  with  one  menu  option,  %all_gl.  This  single  selection  will 
highlight  all  of  the  aid-to-test-pattern  generation  guidelines.  All  of  the  aid-to-test- 
pattern  application  guidelines  may  be  selected  in  a  similar  fashion  via  the  %all_g2 
menu  option.  The  %all  option  indicates  that  all  of  the  aid-to-test-pattern  generation 
guidelines  as  well  as  all  of  the  aid-to-test-pattern  application  guidelines  are  to  be 
invoked.  Selecting  %sill  from  the  menu  will  highlight  all  guidelines  in  the  menu. 
These  grouping  options  are  particularly  useful  when  most  guidelines  of  a  particular 
type  are  to  be  invoked.  Rather  than  selecting  each  guideline  individually,  a  grouping 
selection  may  be  made  followed  by  a  deselection  of  individual  guidelines  to  produce  the 
desired  list. 

Since  this  is  a  multiple  selection  menu,  the  ^done  option  must  be  selected  to  indicate 
that  the  currently  highlighted  guidelines  are  the  ones  to  be  invoked.  The  %done 
option  also  invokes  the  next  menu  which  isolates  the  particular  subsystem  or  subsys¬ 
tems  to  which  the  guidelines  will  be  invoked. 
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Subsystem  Selection 

Since  the  TEA  guidelines  operate  at  the  board  level,  the  user  is  only  given  the  option 
to  chose  boards  to  be  evaluated  with  the  selected  guidelines.  To  specify  a  particular 
board,  the  subsystem  must  first  be  identified.  The  subsystem  menu  contains  all  the 
valid  subsystems  for  the  current  graph  hierarchy.  When  a  particular  subsystem  is 
selected,  all  the  boards  from  that  subsystem  will  then  be  displayed  on  the  next  menu. 
The  %done  option  invokes  the  next  menu  which  is  a  list  of  all  the  boards  from  the 
previously  selected  subsystems.  Figure  11  shows  the  terminal  display  for  the  dft  select 
subsystem  menu. 
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JSdone 
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DFT:  Indicate  the  subsystem (s)  of  Interest: 


Figure  11.  dft  Subsystem  Select  Menu 


Board  Selection 

Only  those  boards  which  reside  on  the  previously  selected  subsystem(s)  are  included  in 
the  board  menu.  Any  combination  of  boards  may  be  selected  from  the  menu.  A 
grouping  option  %a.U  has  been  included  to  ease  the  selection  of  all  the  boards  or  a 
large  portion  of  the  boards.  Once  the  %done  option  has  been  selected,  the  dft 
analyze  tool  is  automatically  invoked.  Figure  12  shows  the  terminal  display  for  the 
dft  select  board  menu. 
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DFT:  Indicate  the  board (s)  of  Interest: 


Figure  12.  dft  Select  Board  Menu 
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The  user-selected  boards  are  analyzed  using  the  user-selected  guidelines.  The  analysis 
is  done  in  Prolog;  therefore,  the  graph  must  be  converted  to  a  format  that  can  be  used 
by  the  Prolog  guidelines.  This  process  takes  a  few  minutes.  Figure  13  shows  the  ter¬ 
minal  display  for  a  typical  dft  analyze  execution  output.  The  boards  are  treated 
independently. 


[compiling  project: [teajgraph.pl. . .] 
[graph.pl  compiled  236.780  sec  78,996  bytes] 
[compiling  project: [teajcontrol.pl. . .] 
[control.pl  compiled  1.950  sec  632  bytes] 

Run  analyze  rules 
running  gl_01 


Figure  13.  dft  analyze  Execution  Output 
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The  output  lines  indicate  that  the  ADAS  graph  is  being  converted  to  Prolog  format 
and  is  then  compiled.  If  a  graph  has  been  compiled  once  and  is  not  modified,  it  will 
not  recompile  during  the  current  session  (e.g.,  a  guideline  executed  on  boardl  can  be 
executed  on  board2  without  having  to  wait  for  the  graph  to  be  recompiled).  The  sub¬ 
system  and  board  selections  are  also  converted  to  Prolog  format  and  compiled.  The 
currently  executing  guideline  is  listed  on  the  output  display. 

Report  Selection 

Upon  completion  of  the  selected  guidelines,  the  user  is  prompted  for  a  filename  in 
which  to  store  a  report  of  the  results  for  later  examination.  A  default  filename  will  be 
provided  if  the  user  chooses  not  to  name  the  file.  The  default  name  used  in  dft 
analyze  is  dftjOl.rpt.  The  two  digit  number  is  included  to  provide  a  unique  filename 
if  multiple  runs  are  made  using  the  default  filename.  If  the  user  types  nl :  at  the 
prompt,  no  output  file  is  created.  If  the  user  selects  an  existing  filename,  a  new  ver¬ 
sion  of  the  file  is  created.  Program  control  is  then  returned  to  the  TEA  top-level 
menu.  Figure  14  shows  the  terminal  display  for  the  dft  analyze  report  prompt. 


r  ~~  ^ 

Enter  <cr>  or  YES  to  accept  dft_01.rpt  as  the  default  filename 
Or  enter  desired  output  filename  : 

V _ _ _ J 

Figure  14.  dft  analyze  Report  Prompt 
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User-defined  Guidelines 

The  user-defined  guidelines  represent  those  guidelines  which  the  user  has  specifically 
generated.  TEA  does  not  provide  any  user-defined  guidelines.  The  user-defined 
guidelines  work  in  the  same  fashion  as  the  standard  ones;  however,  they  are  not 
divided  into  any  specific  categories.  Standard  TEA  guidelines  and  user-defined  guide¬ 
lines  can  NOT  be  invoked  simultaneously.  If  both  standard  TEA  and  user-defined 
guidelines  are  to  be  invoked,  each  type  must  be  invoked  independently. 

TEA  looks  at  the  VMS  logical  tea_rules  to  find  a  filename  where  the  user-defined 
guidelines  are  listed,  one  per  line.  If  the  logical  has  not  been  set,  the  file  tea_rules  is 
used.  Refer  to  the  TEA  Reference  Manual  for  instructions  on  adding  user  guidelines 
to  TEA. 
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The  dft  identify  function  allows  the  user  to  graphically  isolate  a  particular  schematic 
component  (e.g.,  all  memory  elements)  on  the  current  view  display.  The  selection  of 
identify  from  the  dft  options  menu  invokes  the  function  by  displaying  the  subsystem 
selection  menu. 

Subsystem  Selection 

The  user  selects  the  subsystems  of  interest  from  the  current  menu  display.  The  sub¬ 
system  menu  contains  all  the  subsystems  for  the  current  graph  hierarchy.  The 
%done  option  invokes  the  next  menu  which  is  a  list  of  all  the  boards  from  the  previ¬ 
ously  selected  subsystems.  Figure  15  shows  the  terminal  display  for  the  dft  identify 
select  subsystem  menu. 
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Indicate  the  subsystem (s)  of  Interest: 


Figure  15.  dft  identify  Select  Subsystem  Menu 


Board  Selection 

Only  those  boards  which  reside  on  the  previously  selected  subsystem(s)  are  included  in 
the  board  menu.  Once  the  9Sdone  option  has  been  selected,  the  dft  identify  func¬ 
tion  is  invoked.  The  user-selected  boards  are  searched  for  the  requested  construct. 
Figure  16  shows  the  terminal  display  for  the  select  board  menu. 
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===  menu  === 
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board4 
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board 1 

boards 

board 11 

board 16 

board2 

board? 

boardl2 

^  DFT:  Indicate 

the  board  (s) 

of  Interest: 

Figure  16.  dft  identify  Select  Board  Menu 

Identify  Selection 

Figure  17  shows  the  terminal  display  for  the  select  identify 

menu. 

===  menu  === 

JShelp 

f anout>5 

node 

register 
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fllpflop 

one_shot 

scan_reg 

blt_mod 

loop 

primaries 

test_polnt 

counter 

memory 
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^  DFT:  Select  an 

Item  to  be 

Identified: 

Figure  17.  dft  identify  Select  Item  Menu 


Additional  Selections 

dft  identify  contains  a  set  of  predefined  structures  which  may  be  identified  in  the 
current  graph  hierarchy.  Some  structures  require  additional  information  to  correctly 
identify  them  in  an  ADAS  hardware  graph  (i.e,,  loops,  attributes). 

Loops  may  be  identified  by  selecting  the  loop  option  from  the  identify  menu.  The 
user  must  specify  what  types  of  loops  are  to  be  identified.  There  are  three  types  of 
loop  occurrences: 

a.  loops  within  a  specific  board, 

b.  loops  between  boards,  and 

c.  loops  between  subsystems. 
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Figure  18  shows  the  terminal  display  for  the  dft  identify  loop  menu. 

— 

===  menu  === 

%help 
on_board 
brd_betw 
sub  betw 


DFT:  Indicate  the  extent  of  the  loops: 


Figure  18.  dft  identify  loop  Menu 


J 


On-board  loops  are  closed  circuits  which  contain  only  nodes  with  the  same  values  for 
both  Tboard  and  Tsubsystem. 

Loops  of  nodes  between  boards  (or  brd_betw)  are  closed  circuits  which  contain  nodes 
from  two  or  more  of  the  selected  boards  of  each  selected  subsystem  (refer  to  /alues  of 

Tboard  and  Tsubsystem). 

Loops  of  nodes  between  subsystems  (or  sub_betw)  are  closed  circuits  which  contain 
nodes  from  two  or  more  of  the  selected  subsystems  on  selected  boards  (refer  to  values 
of  Tboard  and  Tsubsystem). 

NOTE:  The  loop  routine  is  in  Prolog  which  introduces  a  response  delay  if  the  graph 
has  not  yet  been  converted  to  Prolog  and  compiled. 

ADAS  attributes  with  the  same  value  can  be  identified  by  selecting  the  attribute 
option  from  the  dft  identify  menu.  The  user  must  specify  what  attribute  is  to  be 
identified.  The  list  of  attributes  is  determined  by  the  ‘save_status’  value  for  each 
attribute.  If  the  ‘savejstatus’  value  is  set  to  ‘S’  then  that  attribute  will  appear  in  the 
identify  attribute  menu  list.  Figures  19  and  20  show  the  terminal  displays  for  the 
dft  identify  attribute  menu  and  the  dft  identify  attribute  value  menu  respec¬ 
tively. 
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Figure  20.  dft  identify  attribute  Values  Menu 


Any  of  the  other  options  are  invoked  immediately  after  their  selection  from  the  iden¬ 
tify  menu  (i.e.,  no  submenus). 

Report  Selection 

Upon  completion  of  the  selected  identify  option,  the  user  is  prompted  for  a  filename  in 
which  to  store  a  report  of  the  results  for  later  examination.  A  default  filename  will  be 
provided  if  the  user  chooses  not  to  name  the  file.  Program  control  is  then  returned  to 
the  TEA  top-level  menu.  Figure  21  shows  the  terminal  display  for  the  dft  identify 
report  prompt. 
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f  ^ 

Enter  <cr>  or  YES  to  accept  dft_01.rpt  as  the  default  filename 
Or  enter  desired  output  filename  : 

V _ ! _ 

Figure  21.  dft  identify  Report  Prompt 
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The  dft  explain  function  allows  the  user  to  see  all  the  on-line  information  available 
about  a  particular  guideline,  including  the  purpose  of  the  guideline  and  any  recom¬ 
mended  alternative  constructions.  The  selection  of  explain  from  the  dft  menu 
invokes  the  guideline  menu.  The  two  types  of  guidelines  are 


a.  aid  to  test  pattern  generation  (gl)  and 

b.  aid  to  test  pattern  application  and  fault  isolation  (g2). 


Selecting  gl  invokes  the  next  menu  which  contains  each  specific  guideline  pertaining 
to  test  pattern  generation.  Selecting  g2  invokes  a  menu  which  contains  a  list  of  the 
guidelines  pertaining  to  aiding  test  pattern  application.  Figure  22  shows  the  terminal 
display  for  the  dft  explain  type  menu. 


===  menu  === 

Xhelp 

gl 

g2 


DFT:  Select  the  appropriate  guideline  group: 


Figure  22.  dft  explain  Menu 


Guideline  Selection 

A  single  guideline  may  be  selected  from  the  guideline  menu.  The  guideline  name  is 
used  to  access  the  On-line  User  Support  System  (also  accessible  from  %help)  data 
base  for  the  appropriate  information.  Figure  23  shows  the  terminal  display  for  the  dft 
explain  guideline  menu. 
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menu  === 


%help 

gl  05 

gl  10 

gl  15 

gl  01 

gl  06 

gl  11 

gl_16 

gl  02 

gl  07 

gl  12 

gl_03 

gl  08 

gl  13 

gl_04 

gl_09 

gl_14 

DFT:  Select 

the  specific 

guideline  to  be 

explained : 

Figure  23.  dft  explain  Guideline  Menu 


Report  Selection 

Prior  to  displaying  the  information,  the  user  is  prompted  whether  or  not  to  store  the 
explanation  to  a  file  for  later  examination.  If  the  user  selects  yes,  then  the  informa¬ 
tion  is  written  to  a  file  (the  filename  is  chosen  as  shown  in  Figure  25).  If  the  user 
selects  no,  then  the  information  is  only  displayed  on  the  terminal.  Figure  24  shows  the 
terminal  display  for  the  dft  explain  filename  prompt. 


===  menu  === 

Xhelp 

yes 

no 


Store  the  explanation  to  a  file? 


Figure  24.  dft  explain  Filename  Prompt 


Figure  25  shows  the  terminal  display  for  the  dft  identify  report  prompt,  if  yes  was 
selected  from  the  previous  menu. 


Enter  <cr>  or  YES  to  accept  df t_01 . help  as  the  default  filename 
Or  enter  desired  output  filename  : 

Figure  25.  dft  identify  Report  Prompt 
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BIT  Recommendation  Tool 


The  BIT  Recommendation  Tool,  brt,  aids  the  user  in  determining  whether  determinis¬ 
tic  or  pseudorandom  test  vector  oriented  BIT  techniques  are  advised  for  an  ambiguity 
group.  Brt  determines  the  test  method  for  each  node  from  heuristics,  divides  a  board 
into  ambiguity  groups,  and  then  makes  its  general  BIT  technique  recommendations. 


Subsystem  Selection 

The  brt  function  operates  at  the  board  level,  so  it  is  necessary  that  the  user  provide 
the  name  of  the  specific  board  on  which  the  BIT  recommendation  is  to  be  made. 
Selecting  brt  from  the  TEA  top-level  menu  invokes  the  subsystem  selection  menu. 
The  menu  contains  only  those  subsystems  which  exist  in  the  current  hardware  graph 
hierarchy.  Only  one  subsystem  may  be  selected  for  brt  and  the  next  menu  invoked 
contains  the  various  boards  located  in  the  selected  subsystem.  Figure  26  shows  the 
terminal  display  for  the  brt  subsystem  selection  menu. 


===  menu  === 

JShelp 

subsysl 

subsys2 

subsysS 


subsys4 

subsyeS 

subsyse 


Indicate  the  subsystem  of  interest: 


Figure  26.  brt  Subsystem  Selection  Menu 


Board  Selection 

Only  those  boards  which  are  contained  within  the  selected  subsystem  are  displayed  on 
the  brt  board  selection  menu.  A  single  board  selection  identifies  which  nodes  are  to 
be  involved  in  the  BIT  recommendation.  Selecting  a  specific  board  invokes  the  next 
prompt  which  requests  the  maximum  ambiguity  group  size.  Figure  27  shows  the  ter¬ 
minal  display  for  the  brt  board  selection  menu. 
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^  ===  menu  === 

%help  board4 

board 1  boards 

board2  boards 

boards 

BRT:  Indicate  the  board  of  Interest: 

J 

Figure  27.  brt  Board  Selection  Menu 

Ambiguity  Group  Size  Requirement 

In  order  for  brt  to  determine  an  optimal  ambiguity  grouping  for  the  nodes  on  a  board, 
the  maximum  number  of  nodes  in  ambiguity  group  must  be  known.  The  ambiguity 
group  size  can  be  any  integer  value  greater  than  zero.  The  user  is  prompted  for  the 
group  size  requirement  as  shown  in  Figure  28.  A  value  of  zero  indicates  that  a 
minimum  number  of  ambiguity  groups  of  unrestricted  size  is  to  be  recommended. 
Ambiguity  group  is  abbreviated  AG  in  menus  and  reports. 

BRT:  Enter  desired  AG  size: 

A 

V _ 

J 

Figure  28.  brt  Ambiguity  Group  Size  Limit  Prompt 


Once  the  maximum  ambiguity  group  size  has  been  specified,  the  user  is  asked  whether 
an  altered  cost  function  should  be  used.  If  the  user  responds  with  yes,  then  certain 
groups  will  be  rewarded  or  penalized  (altered  weighting  factors)  for  testability  features 
or  hard-to-test  structures.  See  the  TEA  Reference  Manual  section  2.7.2  for  details.  If 
the  user  responds  with  no,  then  all  enumerated  groups  are  weighted  strictly  on  con¬ 
nectivity.  Figure  29  shows  the  menu  for  this  selection. 
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===  menu  === 

%help 

yes 

no 


BRT:  Alter  cost  function  to  account  for  testability? 


J 


Figure  20.  brt  Cost  Function  Menu 


Report  Selection 

Upon  completion  of  brt,  the  user  is  prompted  for  a  filename  in  which  to  store  the 
results  of  the  tool.  A  default  is  provided  if  the  user  chooses  not  to  enter  a  specific 
filename.  Program  control  is  then  returned  to  the  TEA  top-level  menu.  Figure  30 
shows  the  terminal  display  for  the  brt  report  prompt. 


Enter  <cr>  or  YES  to  accept  brt_01.rpt  as  the  default  filename 
Or  enter  desired  output  filename; 

V _ ! _ ^ _ ) 

Figure  30.  brt  Report  Prompt 
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BIT  Overhead  Summary 


The  BIT  Overhead  Summary  function,  bit_cost,  determines  the  approximate  cost  of 
implementing  a  particular  BIT  technique.  Included  in  the  computation  is  the  number 
of  BIT  modules  and  additional  I/O  that  will  be  needed  to  incorporate  a  specific  imple¬ 
mentation  of  a  BIT  technique.  The  costs  are  itemized  in  an  output  report  file. 


Subsystem  Selection 

The  bit_cost  function  operates  at  the  board  level  so  it  is  necessary  that  the  user  pro¬ 
vide  the  name  of  the  specific  board  where  the  BIT  cost  estimate  is  to  be  made.  Select¬ 
ing  bit_cost  from  the  TEA  top-level  menu  invokes  the  subsystem  selection  menu. 
The  menu  contains  only  those  subsystems  which  exist  in  the  current  hardware  graph 
hierarchy.  Only  one  subsystem  may  be  selected  for  bit_cost.  A  selection  invokes  the 
next  menu  which  contains  the  various  boards  located  in  the  selected  subsystem.  Fig¬ 
ure  31  shows  the  terminal  display  for  the  bit_cost  subsystem  selection  menu. 
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---  menu 

JShelp 

subsysl 

subsys2 

subsysS 


subsys4 

subsysS 

subsysS 


Bit  cost: 


Indicate  the  subsystem  of  Interest: 


Figure  31.  bit_cost  Subsystem  Selection  Menu 


Board  Selection 

Only  those  boards  which  are  contained  within  the  selected  subsystem  are  displayed  on 
the  bit_cost  board  selection  menu.  A  single  board  selection  identifies  which  nodes  are 
to  be  considered.  Selecting  a  specific  board  invokes  the  next  menu  which  requests  the 
BIT  technique(s)  to  be  used  in  the  Overhead  Summary.  Figure  32  shows  the  terminal 
display  for  the  bit_cost  board  selection  menu. 
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Figure  32.  bit_cost  Board  Selection  Menu 


BIT  Technique  Selection 

The  user  must  select  the  BIT  technique(s)  to  be  considered.  The  user  is  prompted  for 
the  technique(s)  to  be  used  as  shown  in  Figure  33. 


r 

'  ===  menu 

%done 

JSall 

tp  sa 

scan  set 

JShelp 

det_tp 

boundary 

gen_sa 

^  Blt_cost: 

Select  BIT 
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J 

Figure  33.  bit_cost  Technique  Selection  Menu 


The  menu  options  represent  the  following  BIT  techniques: 
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a.  det_tp  —  test  point  monitoring  on  a  cycle- by- cycle  basis,  while  applying  ei¬ 
ther  deterministic  or  pseudorandom  patterns  at  the  board  primary  inputs. 
Patterns  are  assumed  to  be  generated  by  using  the  BIT  modules  such  as 
“Testing-Switch,”  “BILBO,”  and  other  available  test  pattern  generator 
modules, 

b.  tp_sa  —  test  point  monitoring  with  compression  of  the  test  output  results, 
while  applying  either  deterministic  or  pseudorandom  patterns  at  the  board 
primary  inputs.  Compression  of  the  test  output  results  is  assumed  to  be  per¬ 
formed  by  using  “BILBO”  modules  as  parallel  signature  analyzers, 

c.  boundary  —  boundary  scan  using  special  registers  at  the  primary  inputs  and 
outputs  of  a  board, 

d.  scanjset  —  board  level  scan-set  technique  using  scan-set  BIT  modules  that 
are  distributed  over  the  board,  and 

e.  gen_sa  —  test  pattern  application  and  response  compression  technique  using 
“Testing-Switch”  modules  that  are  distributed  over  the  board. 


Any  combination  of  techniques  may  be  selected.  The  %all  option  provides  quick 
selection  of  all  techniques.  When  the  desired  techniques  have  been  selected  and  are 
highlighted  on  the  display,  the  %done  option  must  be  selected  to  proceed  to  the  out¬ 
put  report  name  prompt.  The  costs  for  multiple  techniques  are  calculated  indepen¬ 
dently.  TEA  does  not  provide  automated  support  for  multiple  off-line  BIT  techniques 
on  a  single  board. 


Report  Selection 

The  user  is  prompted  for  a  filename  in  which  to  store  the  results  of  the  BIT  Overhead 
Summary.  A  default  is  provided  if  the  user  chooses  not  to  enter  a  specific  filename. 
The  designation  of  a  file  invokes  the  tool  and  produces  an  output  report.  Program 
control  is  then  returned  to  the  TEA  top-level  menu.  Figure  34  shows  the  terminal 
display  for  the  bit_cost  report  prompt.  High  level  information  is  shown  in  the  “.rpt” 
file.  Detailed  information  is  placed  in  the  “.dwg”  file. 


Enter  <cr>  or  YES  to  accept  bltcost_01 . rpt  as  the  default  filename 
Or  enter  desired  output  filename; 

Enter  <cr>  or  YES  to  accept  bltcost_01 . dwg  as  the  default  filename 
Or  enter  desired  output  filename: _ ^ 


Figure  34.  bit_cost  Report  Prompt 
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BIT  Placement  Recommendation 


The  BIT  Placement  Recommendation  function,  placebit,  indicates  to  the  user  where 
to  place  BIT  modules  and/or  test  point  outputs  to  implement  a  particular  BIT  tech¬ 
nique.  BIT  Placement  Recommendation  is  invoked  from  the  TEA  top-level  menu  by 
selecting  the  placebit  option.  Selecting  placebit  invokes  the  BIT  technique  selection 
menu. 


BIT  Technique  Selection 

In  order  for  placebit  to  determine  placement  of  modules  on  a  single  board,  the 
specific  technique  which  is  to  be  applied  must  be  known.  The  user  is  prompted  for  the 
technique  to  be  used  as  shown  in  Figure  35. 


===  menu  === 
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Placebit:  Select  a  BIT  technique: 
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Figure  35.  placebit  Technique  Selection  Menu 


Only  a  single  technique  may  be  applied  at  a  time.  Selection  of  the  desired  technique 
invokes  the  next  menu.  The  techniques  available  are 

a.  det_tp  —  continuous  test  point  monitoring, 

b.  tp_sa  —  test  point  monitoring  with  data  compression, 

c.  boundary  —  board-level  boundary  scan, 

d.  scanjset  —  scan-set, 

e.  gen_sa  —  test  generation  and  response  compression, 

f.  parity  —  on-line  fault  detection  using  parity  generation/checking,  and 

g.  compare  —  on-line  fault  detection  using  equality  comparison. 


Example  Implementation  Selection 

TEA  will  provide  an  example  implementaion  if  the  user  requests  it.  Selecting  yes  from 
the  Example  Implementation  menu  will  cause  the  tool  to  generate  a  properly 
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connected  implementation.  The  no  option  will  bypass  this  example  implementation 
and  general  Instructions  are  given  in  a  file  whose  default  name  is  placebit_n.help. 
Figure  36  shows  the  terminal  display  for  the  placebit  example  implementation  menu. 


Figure  36.  placebit  Example  Implementation  Menu 


Subsystem  Selection 

The  placebit  function  operates  at  the  board  level,  so  it  is  necessary  that  the  user  pro¬ 
vide  the  name  of  the  specific  board  where  the  BIT  placement  recommendation  is  to  be 
made.  The  menu  contains  only  those  subsystems  which  exist  in  the  current  hardware 
graph  hierarchy.  Only  one  subsystem  may  be  selected  for  placebit,  and  its  selection 
invokes  the  next  menu  which  contains  the  various  boards  contained  in  the  selected 
subsystem.  Figure  37  shows  the  terminal  display  for  the  placebit  subsystem  selection 
menu. 


Figure  37.  placebit  Subsystem  Selection  Menu 


Board  Selection 

Only  those  boards  which  are  contained  within  the  selected  subsystem  are  displayed  on 
the  placebit  board  selection  menu.  A  single  l-'oard  selection  identifies  which  nodes  arc 
to  be  involved  in  the  BIT  placement  recommendation.  Selecting  a  specific  board 
invokes  the  next  prompt  which  requests  whether  the  wiring  list  should  be  automati¬ 
cally  placed  or  printed  to  an  output  file.  Figure  38  shows  the  terminal  display  for  the 
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placebit  board  selection  menu. 


===  menu 
J5help 
board 1 
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board4 
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Placebit: 


Indicate  the  board  of  Interest: 


Figure  38.  placebit  Board  Selection  Menu 


Manual  Wiring  List /Autoplacement  Option 

A  wiring  list,  generated  by  placebit,  indicates  the  proper  connectivity  of  the  BIT 
modules  with  the  nodes  on  the  selected  board,  autoplace  will  automatically  update 
the  ADAS  data  base  with  BIT  modules  and/or  test  points.  Three  options  are  provided 
for  obtaining  these  results: 

a.  autoplace  —  for  automatic  placement  and  connection  of  the  BIT  modules  on 
the  current  board, 

b.  wirelist  —  for  printing  a  wiring  list  for  manual  placement  and  connection  of 
the  BIT  modules  on  the  current  board,  and 

c.  %all  —  for  performing  both  an  automatic  placement  as  well  as  providing  a 
wire  list. 

Figure  39  shows  the  terminal  display  for  the  placebit  wirelist  menu. 


===  menu  === 
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Placebit:  Place  and/or  supply  manual  wiring  list? 


Figure  39.  placebit  wirelist  Menu 
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When  selections  have  been  completed,  the  %done  option  invokes  the  output  report 
filename  prompt. 


Report  Selection 

The  user  is  prompted  for  a  filename  in  which  to  store  the  results  of  the  BIT  Placement 
Recommendation,  A  default  is  provided  if  the  user  chooses  not  to  enter  a  specific 
filename.  The  designation  of  a  file  invokes  the  tool  and  produces  an  output  report. 
Program  control  is  then  returned  to  the  TEA  top-level  menu.  Figure  40  shows  the  ter¬ 
minal  display  for  the  placebit  report  prompt  if  autoplace  is  chosen.  A  “.dwg”  will 
not  be  created  if  autoplace  is  not  selected. 

Enter  <cr>  or  YES  to  accept  placeblt_Oi .rpt  as  the  default  filename 
Or  enter  desired  output  filename: 

Enter  <cr>  or  YES  to  accept  placeblt_01 . dwg  as  the  default  filename 
^  Or  enter  desired  output  filename  : _ 

Figure  40.  placebit  Report  Prompt 
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System  Summary 


The  compare  utility  provides  a  method  of  accessing  the  System  Summary  tool  and 
compares  attributes  from  two  ADAS  hardware  graph  data  bases.  The  specific  attri¬ 
bute  information  includes  incremental  changes  in 

a.  node  counts, 

b.  I/O  counts, 

c.  mean  time  to  test,  and 

d.  mean  ambiguity  group  size. 


Directory  Selection 

The  compare  utility  is  invoked  from  the  TEA  top-level  menu  using  the  compare 
command.  The  comparison  will  always  involve  the  currently  displayed  hardware 
graph.  The  other  graph  may  reside  in  some  other  directory  and  therefore  must  be 
identified  by  the  user.  The  first  prompt  provided  after  selecting  compare  from  the 
main  TEA  menu  is  a  request  for  the  directory  of  the  second  graph  as  shown  in  Figure 
41. 


- 

Enter  directory  path  to  search. 

<cr>  or  YES  search  current  dir: 

V _ _ _ y 

Figure  41.  compare  Directory  Search  Prompt 


File  Selection 

Entering  a  valid  directory  (or  using  the  current  as  default)  invokes  the  compare  menu 
which  includes  only  the  hardware  graphs  from  the  specified  directory.  The  user  must 
supply  the  filename  which  indicates  the  hardware  graph  to  be  compared  with  the 
current  view  graph.  An  additional  option,  called  %self  in  the  menu,  allows  compare 
to  run  only  on  the  current  view.  The  %self  option  will  always  be  present  as  a  selec¬ 
tion  no  matter  which  directory  is  specified  at  the  start  of  the  utility.  Figure  42  shows 
the  terminal  display  for  the  compare  options  menu. 
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r 


===  menu  === 
%help 
%self 
fllel .hwg 
flle2.hwg 


Compare : 


Select  the  comparison  graph: 


Figure  42.  compare  Options  Menu 


Selecting  a  single  file  invokes  the  compare  utility.  Two  output  files  are  generated 
from  the  compare  utility: 

a.  general  output  report  (file.rpt)  and 

b.  additional  information  report  (file.dwg). 


Report  Selection 

The  user  is  prompted  for  filenames  for  each  report.  Default  filenames  have  been  pro¬ 
vided.  Figure  43  shows  the  terminal  display  for  the  filename  prompts. 


Enter  <cr>  or  YES  to  accept  coinpare_01 .rpt  as  the  default  filename 
Or  enter  desired  output  filename  : 

Enter  <cr>  or  YES  to  accept  compare_01 .dwg  as  the  default  filename 
Or  enter  desired  output  filename  : 


Figure  43.  compare  Output  Filename  Prompts 


High-level  summary  information  is  placed  in  the  “.rpt”  file.  Lists  of  detailed  informa¬ 
tion  is  placed  in  the  “.dwg”  file. 

The  user  is  notified  if  any  errors  were  detected  in  the  comparison  graphs,  and  program 
control  returns  to  the  TEA  top-level  menu. 
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Ambiguity  Group  Names 


The  Ambiguity  Group  Names  utility,  ag_name,  is  used  to  access  the  ambiguity  group 
(AG)  name  of  any  node.  These  can  be  viewed  and/or  edited.  Ag_name  provides  the 
ability  to  create,  view,  and  edit  special  ambiguity  groups.  Special  ambiguity  groups 
are  user-defined  groups  of  one  or  more  nodes  which  are  to  be  grouped  as  a  single  ambi¬ 
guity  group.  There  is  no  limit  on  the  number  of  special  ambiguity  groups  as  long  as 
there  are  available  nodes.  A  node  may  be  assigned  to  only  one  group. 


Subsystem  Selection 

The  subsystem  of  interest  must  be  selected.  Since  the  ag_name  utility  operates  on  a 
single  board  at  a  time,  only  one  subsystem  may  be  chosen.  Selecting  a  subsystem 
invokes  the  next  menu  which  is  a  list  of  boards  for  the  selected  subsystem.  Figure  44 
shows  the  terminal  display  for  the  ag_name  select  subsystem  menu. 


===  menu 

^help 

subsysl 

subsys2 

subsysS 


subsys4 

subsysS 

subsysS 


Ag_name : 


Indicate  the  subsystem  of  Interest: 


Figure  44.  ag__name  Select  Subsystem  Menu 


Board  Selection 

Only  those  boards  which  reside  on  the  previously  selected  subsystem  are  included  in 
the  board  menu.  Only  a  single  board  may  be  selected  from  the  menu.  Selecting  a 
board  invokes  the  next  menu  which  is  a  list  of  ag_name  options.  Figure  45  shows  the 
terminal  display  for  the  select  board  menu. 
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AG  Name  Selection 

The  ag_name  utility  allows  the  user  to  force  special  nodes  in  a  hardware  graph  to  a 
particular  ambiguity  group.  In  addition,  regular  ambiguity  group  nodes,  which  have 
been  determined  by  the  brt  tool  may  be  modified  using  the  ag_name  utility.  The 
only  restriction  involved  is  that  all  nodes  in  an  ambiguity  group  (regular  or  special) 
must  be  connected.  A  connectivity  checker  is  used  to  determine  if  a  new  or  modified 
group  of  nodes  can  form  an  ambiguity  group. 

Any  category  may  be  invoked  by  selecting  it  from  the  menu.  Figure  46  shows  the  ter¬ 
minal  display  for  the  ag_name  type  menu. 


r 

===  menu  === 

%help 

spcl  ag 

reg_ag 

conn_check 

^  Ag_name:  Modify  special  or  regular  AG: 

J 

Figure  46.  ag_name  Type  Menu 


Special  Ambiguity  Groups 

A  special  ambiguity  group  is  a  collection  of  nodes  that  the  user  wishes  to  be  in  a  group 
together  for  testing.  If  spcl_ag  is  selected  from  the  ag_name  type  menu,  then  a  list 
of  all  the  currently  defined  special  ambiguity  groups  is  displayed  on  a  menu  along  with 
an  option  to  add  a  new  special  ambiguity  group.  Adding  a  new  group  requires  a 
unique  ambiguity  group  name.  Modifying  an  existing  group  is  done  by  selecting  the 
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group  from  the  menu.  Figure  47  shows  the  terminal  display  for  the  select  spcl_ag 
menu. 


===  menu  === 

%help 

%add_new 

spag_l 

spag_2 

Ag_name:  Indicate  the  special  AG  of  Interest: 


Figure  47.  spcl_ag  Select  Menu 


Add  New  Special  AG 

A  new  special  ambiguity  group  name  must  be  unique  to  the  existing  ambiguity  group 
names.  Once  a  unique  name  has  been  entered,  the  next  menu  is  invoked  which  gives  a 
ILb  of  all  the  nodes  for  the  currently  selected  board.  Figure  48  shows  the  terminal 
display  for  the  spcl_ag  add_new  name  menu. 

Ag_name:  Input  the  name  for  the  special  AG: 


Figure  48.  ag_naine  Prompt 


Nodes  in  New  Special  AG 

The  user  is  prompted  to  select  those  nodes  from  the  selected  board  which  are  to  be  in 
the  new  special  AG.  The  nodes  listed  in  the  menu  do  not  represent  any  form  of  con¬ 
nectivity.  When  all  nodes  have  been  selected  for  the  new  group,  and  the  %done 
option  has  been  selected,  the  utility  invokes  the  connectivity  checker  to  verify  that  the 
entered  nodes  represent  a  valid  (connected)  group.  If  the  group  is  valid,  and  creating 
it  did  not  disturb  the  connectivity  of  the  other  AGs  on  the  board,  then  program  con¬ 
trol  is  returned  to  the  TEA  top-level  menu.  If  the  group  is  Invalid,  however,  a  report 
is  output  and  then  control  is  returned  to  the  top-level  menu.  Figure  49  shows  the  ter¬ 
minal  display  for  the  add_new  spcl_ag  menu. 
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===  menu  === 

%help 

%done 

node_l 

node_2 

node_3 

Ag_name:  Indicate  the  node(s)  of  Interest: 


Figure  40.  ag_name  Node  Menu 


Modifiy  Existing  Special  AG 

Any  of  the  existing  special  AGs  may  be  edited  by  selecting  the  existing  AG  name  from 
the  special  AG  menu.  The  special  AG  menu  contains  all  of  the  specially  defined  AGs 
for  the  current  board.  When  exiting,  the  connectivity  checker  will  run. 


Regular  Ambiguity  Groups 

Nodes  which  have  been  previously  assigned  to  ambiguity  groups  via  the  brt  tool  may 
be  reorganized  by  selecting  the  group  from  the  ag_name  group  menu  and  the  nodes  to 
be  included  in  the  AG  from  the  ag_name  node  menu.  Figures  50  and  51  show  the 
terminal  display  for  the  ag_name  group  and  ag_name  node  menus,  respectively. 


Figure  50.  ag_name  Group  Menu 
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===  menu 

%help 

%done 

nodel 

node2 

nodes 


node4 

nodes 

nodes 

node? 


Ag_ 


name : 


Indicate  the  nodes  of  Interest: 


Figure  51.  ag_name  Node  Menu 


The  choices  will  be  checked  for  valid  connectivity.  Ag_name  does  not  allow  for  the 
addition  of  new  regular  AGs. 


Report  Selection 

Upon  completion  of  ag_name  spcl_ag  add_new,  the  user  is  prompted  for  a  report 
name  in  which  to  store  the  results  of  the  tool  if  there  is  an  error  in  the  connectivity  of 
the  ambiguity  groups.  A  default  is  provided  if  the  user  chooses  not  to  enter  a  specific 
report  name.  Program  control  is  then  returned  to  the  TEA  top-level  menu.  Figure  52 
shows  the  terminal  display  for  the  ag_name  report  prompt. 


Enter  <cr>  or  YES  to  accept  ag_name_01 . rpt  as  the  default  filename 
Or  enter  desired  output  filename  : 

L ! _ ) 

Figure  52.  ag_name  Report  Prompt 


Connectivity  Check 

This  option  allows  the  user  to  check  for  connectivity  between  ambiguity  groups. 
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Report  Access/Generation 


The  log_fiIe  utility  allows  the  user  to  access  the  results  of  any  of  the  TEA  tools. 
Selecting  log_file  from  the  TEA  top-level  menu  invokes  the  Log  File  Type  selection 
menu. 

The  log_file  utility  provides  two  main  functions  for  any  on-line  TEA  tool  reports  or 
wiring  diagrams: 


a.  view  —  for  displaying  a  report,  help,  or  wiring  diagram  on  the  terminal 
display  and 

b.  print  —  for  producing  hardcopy  reports  on  a  local  printer. 

Figure  53  shows  the  terminal  display  for  the  log_file  menu. 


===  menu  === 

JShelp 

view 

print 

Logflle:  View  or  print  report? 


Figure  53.  log_file  Menu 


Viewing  Reports 

Any  report  may  be  viewed  if  the  user  has  proper  access.  Selecting  view  from  the 
log_file  type  menu  invokes  a  prompt  for  the  directory  to  be  searched  for  report  files. 
The  default  is  the  current  directory  and  is  used  only  when  a  ‘yes’  response  or  carriage 
return  is  entered  in  response  to  the  directory  prompt.  Figure  54  shows  the  terminal 
display  for  the  directory  prompt. 

- 

Enter  directory  path  to  search. 

<cr>  or  YES  searches  current  dir: 

V _ _ _ ) 

Figure  54.  log_file  Directory  Search  Prompt 
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Indicating  the  appropriate  directory  invokes  a  search  of  that  directory  for  report  files. 
Those  report  files  are  displayed  on  the  next  menu.  Figure  55  shows  the  terminal 
display  of  report  files  from  a  particular  directory. 


===  menu  === 
%help 
fllel .rpt 
flle2 .help 
files. dwg 


Log_flle: 


Select  a  report: 


Figure  55.  log_file  Report  Options  Menu 


Selecting  a  report  file  from  the  menu  displays  that  file  in  page  lengths  on  the  terminal 
screen.  The  user  may  scroll  through  the  file  by  entering  a  carriage  return  after  each 
page  is  displayed.  The  view  option  is  identical  to  a  VMS  type/page  command. 


Printing  Reports 

Printing  a  report  is  similar  in  operation  to  viewing  except  that  the  print  option  is 
selected  from  the  log_file  menu.  The  sequence  of  menus  and  prompts  is  identical. 
The  printer  used  is  the  user’s  default  printing  device.  Alternate  printers  may  NOT  be 
accessed  via  the  TEA  log_file  utility. 
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On-line  User  Support  System 


All  TEA  selection  menus  provide  on-line  user  support  via  the  %help  menu  option. 
Selecting  %help  provides  default  information  which  corresponds  to  the  most  useful 
information  based  on  the  menu  currently  being  displayed.  The  %help  function 
operates  identically  to  the  VMS  help  facility.  The  user  always  has  the  option  to  access 
any  part  of  the  %help  on-line  information  by  typing  a  “?”  at  the  topic  prompt.  A 
“?”  will  display  the  current  areas  of  help  which  are  available.  A  carriage  return  will 
either  back  the  user  out  of  the  help  hierarchy  by  one  level  or  exit  help  if  the  user  is 
already  at  the  top  level.  Typing  the  name  of  a  selection  followed  by  a  carriage  return 
selects  that  information  and  any  subtopic  items  will  be  displayed.  Figure  56  shows  the 
terminal  display  of  on-line  topics. 


r 


Information  available: 


Functions  Libraries  Menus 


Tools 


Utilities 


Topic? 


Figure  56.  TEA  On-line  Topics  Menu 


From  the  On-line  Topics  menu,  the  user  may  proceed  to  any  desired  on-line  informa¬ 
tion.  On-line  help  is  NOT  provided  for  TEA  prompts  which  do  not  generate  a  menu. 
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ALPHABETICAL  LIST  OF  TEA  ERROR  MESSAGES 


The  following  list  of  error  messages  is  sorted  alphabetically  by  command  code  (columns 
6-7)  and  numerically  by  error  number  within  a  command.  Each  entry  lists  the  mean¬ 
ing  of  the  error  message  and  the  action  that  must  be  taken  to  correct  the  error.  The 
standard  ADAS  error  message  format  is  explained  the  ADAS  User  Manual,  Version  2.3 
or  later. 

***  ZAG  002A  —  Out  of  memory. 

Meaning:  The  computer’s  available  memory  has  been  exceeded. 

Action:  Re-run  with  more  computer  memory. 

***  ZBB  OOlE  —  No  valid  nodes  to  make  ambiguity  groups. 

Meaning:  There  are  no  valid  nodes  in  the  current  graph. 

Action:  Check  subsystem  and  board  attribute  values. 

***  ZBB  002A  —  No  solution  found. 

Meaning:  Nodes  cannot  be  formed  into  ambiguity  groups. 

Action:  Contact  RTI  for  assistance. 

***  ZBB  004A  —  Could  not  set  up  initial  basis  for  simplex. 

Meaning:  Could  not  form  nodes  into  AG’s  of  size  one. 

Action:  Contact  RTI  for  assistance. 
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***  ZBM  OOOW  —  Invalid  directory  path  path 

Meaning:  Specified  directory  path  does  not  exist. 

Action:  Re-enter  correct  path. 

***  ZBR  001 W  —  Can’t  access  BRT  library. 

Meaning:  The  location  of  the  BRT  library  has  not  been  properly  identified. 
Action:  Check  TEA_BRT  define  in  TEA  setup  file. 

***  ZBR  002E  —  Illegal  ambiguity  group  size. 

Meaning:  The  integer  entered  for  ambiguity  group  size 
must  be  positive. 

Action:  Re-enter  the  ambiguity  group  as  a  positive  integer. 

***  ZCA  OOlE  —  Node  name  could  not  be  interpreted. 

Meaning:  The  node  selection  was  incorrect. 

Action:  Re-enter  the  node  name  at  the  keyboard  or  select  the  name  from 
the  display  menu  or  graph. 

***  ZCA  002E  —  Node  (or  bus)  location  could  not  be  interpreted. 

Meaning:  The  given  coordinates  contained  an  error. 

Action:  Re-enter  the  location. 
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*** 


*** 


*** 


ZCA  003E  —  Arc  could  not  be  interpreted. 

Meaning:  Arc  selection  was  incorrect. 

Action:  Re-enter  name. 

ZCA  004E  —  An  error  occurred.  Please  check  the  input. 

Meaning:  An  unspecified  error  was  found. 

Action;  Check  the  input  and  re-enter. 

ZCI  OOIE  —  Command  is  not  a  unique  name. 

Meaning:  The  command  cannot  be  selected  from  the  command  list  because 
there  are  ambiguous  choices. 

Action:  Re-enter  the  command  with  enough  information  to  make  a  unique 
selection. 

ZCI  002E  —  An  error  occurred  in  your  selection.  String  is  an 
incorrect  response.  Please  reenter  this  item. 

Meaning:  Command  entered  was  not  on  menu  or  was  an  incorrect  response. 

Action:  Re-enter  command. 

ZCM  004A  —  File  name  cannot  be  found. 

Meaning:  Source  graph  listed  on  the  command  line  cannot  be  found. 

Action:  Check  graph  filename  or  location. 
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*** 


*** 


ZCO  OOlE  —  Too  many  repetitions  requested. 

Meaning:  The  upper  limit  for  repeating  a  command  was  exceeded. 
Action:  Re-enter  a  smaller  number. 

ZDB  OOlA  —  There  are  no  more  unused  graph  descriptors. 

Meaning:  The  graph  is  full. 

Action:  Contact  RTI  for  help. 

ZDB  003A  —  The  template  file  cannot  be  accessed. 

Meaning:  Cannot  open  data  base  file  for  reading. 

Action:  Check  read  access  of  graph  file. 

ZDB  005A  —  Premature  end-of-file  encountered  while  reading  template 
file  file. 

Meaning:  It  is  likely  that  the  file  has  been  damaged,  since  part 
of  its  data  is  missing. 

Action:  Examine  the  template  file  using  EDIGRAF.  If  it  has  been 
damaged,  recreate  it.  Periodically  creating  backup 
copies  of  important  data  base  files  limits  the  extent 
of  this  kind  of  damage. 

ZDB  006A  —  The  template  file  cannot  be  read. 

Meaning:  The  template  file’s  contents  are  not  interpretable. 

Action:  Make  sure  that  the  proper  template  file  is  being  used. 
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*** 


*** 


*** 


*** 


*** 


ZDB  007A  —  Not  enough  memory  to  expand  graph. 

Meaning:  Expanding  this  graph  would  exceed  the  computer’s 
available  memory. 

Action:  Divide  the  graph  nodes  into  subgraphs. 

Contact  RTI  if  further  help  is  needed. 

ZDF  OOOA  —  Can’t  start  prolog  servant. 

Meaning:  The  prolog  code  can  not  be  invoked. 

Action:  See  local  ADAS  administrator  for  proper  prolog  installation. 

ZDF  OOlW  —  Can’t  create  control  file  in  current  directory. 

Meaning:  A  prolog  control  file  is  needed  and  it  cannot  be 
written  in  this  directory. 

Action:  Check  write  access  in  this  directory. 

ZDF  (K)2A  —  Can’t  open  user  rules  file. 

Meaning:  The  user’s  prolog  code  can  not  be  accessed. 

Action:  See  local  ADAS  administrator. 

ZED  OOlE  —  Value  name  has  an  invalid  format. 

Meaning:  Format  of  the  attribute  value  is  inconsistent  with  its 
data  type.  Spaces  and  tabs  are  not  accepted. 

Action:  Correct  the  information  and  retry. 
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***  ZED  002E  —  Value  name  is  out  of  range. 

Meaning:  Value  of  a  numerical  attribute  is  out  of  range. 

Action:  Correct  the  information  and  retry. 

***  ZED  003E  —  Attribute  att  is  not  modifiable. 

Meaning:  The  modification  status  for  the  named  attribute  does  not 

permit  the  value  of  the  attribute  to  be  changed  in  the  editor 
(i.e.,  ‘N’). 

Action:  Use  the  edit  status  command  to  change  the  status. 

***  ZED  004E  —  Value  name  is  not  a  valid  name. 

Meaning:  Name  is  not  a  correct  ADAS  graph  element  name. 

Action:  Check  the  ADAS  User  Manual,  Version 
2.3  or  later,  for  correct  name  rules. 


***  ZED  OOSW  —  Status  of  attribute  att  for  graph  element 
is  not  modifiable. 

Meaning:  The  modification  status  for  the  named  attribute  does  not 

permit  the  value  of  the  attribute  to  be  changed  in  the  editor. 

Action:  Use  the  edit  status  command  to  change  the  status. 


***  ZED  006W  —  Special  characters  ignored. 

Meaning:  The  special  characters  are  not  used  in  the  current 
edit  mode. 

Action:  Enter  a  new  value,  cancel  the  edit  session,  or  go  on 
to  the  next  selection  with  a  <RET>. 
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***  ZED  007W  —  There  is  no  portjtype  number  for  node  name. 
Meaning:  The  port  is  not  of  this  type. 

Action:  No  action  required. 


***  ZED  OOSW  —  Count  more  attempts.  Try  again. 

Meaning:  Count  more  attempts  at  modifying  the  current 

attribute  will  be  allowed  before  going  on  to  the  next 
attribute. 

Action:  Refer  to  the  ADAS  User  Manual,  Version  2.3 

or  later,  for  proper  values  of  the  current  attribute. 


***  ZED  009W  —  No  more  attempts.  Continuing  edit. 

Meaning:  After  previous  attempts  to  modify  the  current  attribute 
have  failed,  the  editor  is  moving  on  to  the  next  attribute. 

Action:  See  the  ADAS  User  Manual,  Version  2.3 

or  later,  for  the  valid  attribute  values  of  the  current 
attribute  and  attempt  to  edit  the  attribute  again. 


***  ZED  OlOW  —  No  port  types/junctions/connections  for  node/bus  name,  skipping. 

Meaning:  The  node/bus  name  does  not  have  any  ports  of  the 
named  type. 

Action:  No  action  required. 


***  ZED  01 IW  —  No  arc  on  port_type  number  node  name,  skipping. 

Meaning:  The  node/bus  name  does  not  have  any  ports  of  the 
named  type. 

Action:  No  action  required. 
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*** 


*** 


*** 


*** 


*  ** 


ZED  012W  —  Attribute  att  for  graph  element, 
is  not  modifiable. 

Meaning:  The  modification  status  for  the  named  attribute  does  not 

permit  the  value  of  the  attribute  to  be  changed  in  the  editor. 

Action:  Use  the  edit  status  command  to  change  the  status. 

ZED  013W  —  Attribute  att  is  not  present  in  the  template  data  base. 
Meaning:  This  data  base  does  not  have  an  attribute  of  this  name. 
Action:  Check  attribute  name. 


ZGD  OOIA  —  Can’t  create  graph.pl. 

Meaning:  graph.pl  is  the  prolog  data  base  of  the  ADAS  graph 
hierarchy  and  the  file  cannot  be  written. 

Action:  Check  write  access  in  this  directory. 


ZHC  OOIA  —  Can’t  reinitialize  current  graphics  device  dev. 

Meaning:  After  the  hardcopy  device  was  initialized,  an  error  occurred 
in  reinitializing  the  normal  display  device. 

Action:  Begin  a  new  TEA  session. 


ZHC  002E  —  Can’t  initialize  hardcopy  device  dev. 

Meaning:  The  initialization  of  the  hardcopy  device  failed. 

Action:  Make  sure  the  hardcopy  device  is  plugged  in,  turned  on, 
and  properly  initialized. 
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***  ZHC  003E  —  Can’t  open  hardcopy  file  name. 

Meaning:  The  file  containing  the  current  list  of  valid 
hardcopy  devices  cannot  be  accessed. 

Action:  Check  with  the  local  ADAS  administrator. 

***  ZHE  OOlE  —  Can’t  open  help  file  file. 

Meaning:  The  specified  help  file  either  could  not  be  found 
or  could  not  be  read. 

Action:  Check  with  the  local  ADAS  administrator. 

***  ZIN  OOlE  —  Input  exceeded  maximum  line  length  of  linelength. 

Meaning:  Too  many  characters  were  given  at  the  keyboard. 

Action:  Re-enter. 

***  ZIN  002E  —  Input  line  ignored. 

Meaning:  An  error  was  found  in  the  input,  or  the  entry  was  irrelevant. 
Action:  Re-enter. 

***  ZIN  003E  —  r  j,ta  tablet  error  occurred. 

Meaning:  An  error  occurred  in  the  data  tablet. 

Action:  Try  again,  or  contact  local  systems  help  or  RTI. 
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***  ZIN  004E  —  Unspecified  error  from  graphics  package. 
Meaning:  An  error  occurred  in  a  graphics  device. 

Action:  Try  again,  or  contact  local  systems  help  or  RTI. 


***  ZIN  005A  —  Unexpected  end  of  input  encountered. 

Meaning:  The  input  to  the  program  terminated  unexpectedly. 

Action:  If  the  keyboard  or  data  tablet  was  in  use  when  the  error 
occurred,  no  action  is  necessary.  If  the  input  was  from  a 
script  file,  the  file  contains  errors  and  should  be  checked. 
If  the  input  was  from  a  file  other  than  a  script  file, 
check  for  the  proper  session  termination  commands, 
e.g.,  quit  nosave. 


***  ZMA  001 A  —  Unknown  option  name. 

Meaning:  The  command  line  option  name  was  invalid. 
Action:  Re-enter  the  correct  command  line. 


***  ZMA  002A  —  No  graphics  display  specified. 

Meaning:  No  graphics  device  was  specified. 

Action:  A  graphics  device  must  be  specified. 

Re-enter  the  correct  command  line. 


***  ZMA  004A  —  Couldn’t  open  graphics  device  name. 

Meaning:  A  valid  graphics  device  was  specified  but  is 
either  inoperable  or  in  use. 

Action:  Either  use  a  different  device  or  try  again  later. 


TEA:  The  Test  Engineer’s  Assistant,  SSUM,  p.  Z-55 


ALPHABETICAL  LIST  OF  TEA  ERROR  MESSAGES,  Cont. 


***  ZMA  005A  —  No  data  base  specified. 

Meaning:  No  data  base  was  specified  on  the  command  line. 

Action:  Specify  the  correct  data  base. 

***  ZMC  OOlE  —  Macro  not  added.  At  maximum  number  of  macros. 

Meaning:  The  maximum  allowable  number  of  macros  already  exists. 

Action:  Either  remove  a  current  macro  to  add  another,  or  do  not  try 
to  add  a  macro. 

***  ZMC  002E  —  Macro  name  not  valid.  1st  character  non-alphabetic. 

Meaning:  The  first  character  of  any  macro  command  must  be  a 
letter  of  the  alphabet. 

Action:  Choose  another  macro  name  that  is  acceptable. 

***  ZMC  003E  —  Macro  name  is  already  in  menu. 

Meaning:  The  macro  name  is  in  conflict  with  another  identical  name. 
Action:  Use  a  different  and  unique  name. 

***  ZMC  004E  —  No  macro  name  provided. 

Meaning:  When  defining  a  macro,  the  name  was  not  included. 

Action:  Re-enter  using  a  specific  and  unique  name. 
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*** 


*** 


*** 


ZMC  005E  —  Too  many  macro  parameters  provided. 

Meaning:  There  is  a  limit  to  the  number  of  parameters  that  a  macro 
definition  may  have. 

Action:  Re-enter  the  macro  definition. 

ZMC  006E  —  Macro  is  undefined. 

Meaning:  An  error  was  found,  and  the  macro  was  not  defined  as  a  result. 
Action:  Redefine  macro. 

ZMC  007E  —  Macro  not  added.  Menu  item  limit  exceeded. 

Meaning:  There  is  a  limit  to  the  number  of  menu  items  that  are  allowed. 
Action:  Delete  a  macro  in  order  to  add  a  new  one. 

ZMC  008E  —  No  macros  to  be  deleted. 

Meaning:  The  macro  list  is  empty. 

Action:  None. 

ZMC  009E  —  No  macros  to  be  listed. 

Meaning:  There  are  no  macros  currently  defined. 

Action:  None 
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*** 


*** 


*** 


*** 


ZMN  OOIA  —  Out  of  memory. 

Meaning:  TEA  ran  out  of  memory. 

Action:  Contact  RTI  for  assistance. 

ZMN  002E  —  Insufficient  memory  to  create  menu. 

Meaning:  TEA  ran  out  of  memory. 

Action:  Contact  RTI  for  assistance. 

ZMN  003E  —  Can’t  delete  item  name:  not  in  menu. 

Meaning:  Deletion  cannot  be  performed  since  item  is  not  present. 
Action:  None. 

ZMN  004E  —  Item  itemjname  is  already  in  menu. 

Meaning:  The  item  name  is  not  unique. 

Action:  Rename  the  item  with  a  unique  name. 

ZMS  OOOW  —  Reloading  graph  graphname. 

Meaning:  The  graph  graphname  is  being  reloaded  from 
the  disk  file. 

Action:  No  action. 
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***  ZPB  OOOA  —  Fatal  template  load  error. 

Meaning:  The  template  file  corresponding  to  the  current 
graph  cannot  be  loaded  properly. 

Action:  Make  sure  that  a  template  file  exists  in  the  proper 
directory  corresponding  to  the  current  graph. 

***  ZPO  OOlE  —  Port  mismatch  between  node  name  and  subgraph  name. 

Meaning:  A  graph  output  has  been  assigned  to  more  or  less 
than  one  node. 

Action:  Adjust  subgraph  consistency. 

***  ZPO  002E  —  Too  many  node  ports  on  graph  port  number  in  subgraph  name 

Meaning:  There  is  a  graph  port  with  too  many  node  ports. 

Action:  Remove  the  extra  ports  or  adjust  subgraph  consistency. 

***  ZPO  003E  —  No  arc  connected  to  graph  port  number  in  subgraph  name. 

Meaning:  There  is  a  graph  port  with  no  attached  arcs. 

Action:  Add  arcs  to  graph  port,  appropriately  remove  graph  port,  or 
adjust  subgraph  consistency. 

***  ZPS  OOOA  —  Can’t  open  BIT  template  file. 

Meaning:  The  template  file  associated  with  the  graph  is  not 
present  or  cannot  be  accessed  for  some  reason. 

Action:  Make  sure  that  the  template  file  has  the  correct  name 
and  proper  read/write  permissions. 
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*** 


*** 


*** 


*** 


ZPS  OOlE  —  Arc  template  not  found.  Can’t  reroute  port  portH^. 

Meaning:  The  arc  template  of  the  arc  being  rerouted  is  not 
present  or  cannot  be  accessed  for  some  reason. 

Action:  Make  sure  that  the  template  file  has  the  correct  arc 
template. 


ZPS  0C)2E  —  Arc  template  not  found.  Can’t  intercept  port  port#. 

Meaning:  The  arc  template  of  the  arc  being  intercepted  is  not 
present  or  cannot  be  accessed  for  some  reason. 

Action:  Make  sure  that  the  template  fde  has  the  correct  arc 
template. 


ZPS  003W  —  Node  nodename  had  Tag_name  and  Tsp_ag_name  set. 
Meaning:  Both  attributes  are  set  in  the  current  graph. 

Action:  Delete  one  attribute  entry  so  that  there  is  only  one  set. 

ZRE  OOlE  —  Can’t  access  subgraph  data  base  file. 

Meaning:  The  data  base  file  associated  with  the  subgraph  is  not 
present  or  cannot  be  accessed  for  some  reason. 

Action:  Make  sure  that  the  file  has  the  correct  name 
and  proper  read/write  permissions. 

ZRE  002E  —  Can’t  read  subgraph  data  base  name. 

Meaning:  There  was  an  error  in  reading  the  file. 

Action:  Contact  RTI  for  assistance. 
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ZRE  003E  —  Premature  EOF  encountered  while  reading  subgraph  data  base  name. 

Meaning:  It  is  likely  that  the  file  has  been  damaged  since 
part  of  the  data  is  missing. 

Action:  Examine  the  file  using  EDIGRAF.  If  it  has  been 
damaged,  recreate  it.  Periodically  creating  backup 
copies  of  important  data  base  files  limits  the 
extent  of  this  kind  of  damage. 


ZRE  004E  —  Not  enough  memory  to  read  in  subgraph  data  base. 

Meaning:  Expanding  the  subgraph  would  exceed  the  computer’s 
available  memory. 

Action:  Divide  the  subgraph  into  lower  level  subgraphs. 


ZRE  OOSE  —  Error  in  reading  subgraph  data  base  name. 
Meaning:  There  was  an  error  in  reading  the  file. 
Action:  Contact  RTI  for  assistance. 


ZRE  006A  —  Can’t  reinitialize  graph  data  base. 

Meaning:  The  in-memory  data  base  could  not  be  Initialized  upon  reloading. 
Action:  Contact  RTI  for  assistance. 


ZRE  007A  —  Can’t  access  graph  data  base  name. 

Meaning:  The  data  base  file  associated  with  the  graph  is  not 
present  or  cannot  be  accessed  for  some  reason. 

Action:  Make  sure  that  the  file  has  the  correct  name 
and  proper  read/write  permissions. 
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*** 


*** 


*** 


ZRE  008A  —  Can’t  read  graph  data  base  name. 

Meaning:  There  was  an  error  in  reading  the  file. 

Action:  Contact  RTI  for  assistance. 

ZRE  009A  —  Premature  EOF  encountered  while  reading  graph  data  base  name. 

Meaning:  It  is  likely  that  the  file  has  been  damaged  since 
part  of  the  data  is  missing. 

Action:  Examine  the  file  using  TEA.  If  it  has  been 

damaged,  recreate  it.  Periodically  creating  backup 
copies  of  important  data  base  files  limits  the 
extent  of  this  kind  of  damage. 

ZRE  OlOA  —  Not  enough  memory  to  read  in  graph  data  base. 

Meaning:  Expanding  this  graph  would  exceed  the  computer’s 
available  memory. 

Action:  Divide  the  graph  into  subgraphs. 

ZRE  Oil  A  —  Error  in  reading  graph  data  base  name. 

Meaning:  There  was  an  error  in  reading  the  data  base. 

Action:  Contact  RTI  for  assistance. 

ZRE  012W  —  Reloading  subgraph  name. 

Meaning:  The  current  subgraph  is  being  reloaded  from  its 
external  file. 

Action:  None 
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*** 


*** 


*** 


ZRE  013E  —  Can’t  reload  subgraph  name. 

Meaning:  There  was  an  error  in  reading  subgraph  file  name. 
Action:  Contact  RTI  for  assistance. 

ZRE  014W  —  Now  editing  parent  graph  name. 

Meaning:  Parent  graph  name  is  the  current  graph. 

Action:  None 

ZRE  015W  —  Reloading  graph  name. 

Meaning:  The  current  graph  name  is  being  reloaded  from  its 
external  file. 

Action:  None 

ZRG  OOOA  —  Make  report  can’t  open  filename. 

Meaning:  The  file  filename  cannot  be  opened  by  the 
report  generator. 

Action:  Check  access  permissions  in  the  directory. 

ZRG  OOlW  —  Can’t  create  output  file  filename. 

Meaning:  The  file  filename  cannot  be  opened  by  the 
report  generator. 

Action:  Check  access  permissions  in  the  directory. 
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***  ZSA  OOlW  —  Updated  graph  name. 

Meaning:  The  current  graph  data  base  was  saved. 

Action:  None. 

***  ZSA  002W  —  Created  new  graph  name. 

Meaning:  Current  graph  saved  under  a  new  filename. 

Action:  None. 

***  ZSA  003W  —  Cannot  open  graph  data  base  name  for  writing. 

Meaning:  The  data  base  file  and/or  directory  associated  with  the  graph 
does  not  have  write  permission. 

Action:  Make  sure  that  the  data  base  file  and/or  directory  has  the 
correct  name  and  proper  write  permissions. 

***  ZSA  (X)4W  —  Graph  data  base  not  saved. 

Meaning:  The  current  graph  and  results  of  this  session  were 
not  saved. 

Action:  Run  TEA  again. 

***  ZSA  005W  —  Template  data  base  file  not  saved. 

Meaning:  The  current  cemplate  and  results  of  this  session  were 
not  saved. 

Action:  Run  TEA  again. 
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*** 


*** 


ZSA  006W  —  Created  a  copy  of  name  as  namel. 

Meaning:  A  new  copy  of  the  graph  has  been  stored  as 
requested. 

Action:  None. 

ZSA  008E  —  File  name  does  not  have  a  valid  extension. 

Meaning:  File  names  must  have  a  hardware  graph  name, 
including  extension  (.hwg). 

Action:  Check  the  filename. 

ZSA  009W  —  File  name  already  exists. 

Meaning:  A  file  with  this  name  already  exists. 

Action:  Choose  a  unique  name. 

ZSA  007E  —  File  name  was  incorrectly  copied. 

Meaning:  Report  of  unsuccessful  termination  of  save. 

Action:  Retry  save  or  check  write  access. 

ZSC  OOlE  —  Input  exceeded  maximum  line  length  of  max  length 
Meaning:  There  is  a  line  length  limit  that  was  exceeded. 
Action:  Re-enter  using  shorter  string. 
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*** 


*** 


ZSC  002E  —  Input  line  ignored. 

Meaning:  An  error  occurred  or  the  input  line  was  irrelevant. 
Action:  Check  input  and  command  prompt. 

ZSC  003E  —  Cannot  open  script  file  name. 

Meaning:  The  script  file  name  does  not  exist  or  does 
not  have  the  proper  read/write  permissions. 

Action:  Check  for  the  file’s  existence  and  proper  permissions. 

ZSC  C)04E  —  Due  to  an  input  error  all  script  files  have  been  closed. 
Meaning:  An  error  has  occurred  in  a  script  file. 

Action:  Fix  script  file. 

ZST  OOlA  —  Out  of  memory. 

Meaning:  TEA  ran  out  of  memory. 

Action:  Contact  RTI  for  assistance. 

ZSU  OOlE  —  At  maximum  depth  in  hierarchy. 

Meaning:  Only  20  levels  of  hierarchy  are  allowed. 

Action:  Change  the  structure  of  the  graph  so  that 
fewer  levels  are  required. 


TEA:  The  Test  Engineer’s  Assistant,  SSUM,  p.  Z-60 


ALPHABETICAL  LIST  OF  TEA  ERROR  MESSAGES,  Cont. 


***  ZSU  002E  —  No  subgraphs  found  in  this  graph. 

Meaning:  The  subgraf  command  cannot  be  issued  since 

there  are  no  subgraphs  associated  with  the  current  graph. 

Action:  Use  EDIGRAF  to  alter  the  structure  of  the  graph. 

***  ZTC  OOOW  —  File  filename  cannot  be  found. 

Meaning:  The  second  graph  involved  in  the  compare  cannot 
be  isolated  according  to  the  name  entered. 

Action:  Check  the  filename  and  location  of  the  second  graph. 

***  ZTR  OOlE  —  Couldn’t  open  subgraph  name. 

Meaning:  While  trying  to  expand  the  root  graph,  a  subgraph 

was  encountered  that  exists  but  could  not  be  opened. 

Action:  Check  the  permissions  of  the  file  containing  the  subgraph 
data  base  to  see  if  it  is  readable. 


***  ZTR  002E  —  Premature  end-of-file  while  reading  subgraph  data  base  name. 

Meaning:  TEA  hit  end-of-file  while  reading  the  subgraph 
data  base. 

Action:  Examine  the  template  file  using  EDIGRAF.  If  it  has  been 
damaged,  recreate  it.  Periodically  creating  backup 
copies  of  important  data  base  files  limits  the  extent 
of  this  kind  of  damage. 
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***  ZTR  003A  --  Ran  out  of  memory  trying  to  read  subgraph  data  base  name. 
Meaning;  Graph  too  big. 

Action:  Reduce  the  size  of  the  main  graph  by  dividing  it  into 

subgraphs.  Simulate  individual  subgraphs;  then  propagate 
information  upwards  by  editing  the  parent  nodes’  attributes. 


***  ZTS  OOIA  —  Can’t  find  prolog  results  file. 

Meaning:  The  results  posted  by  prolog  are  not  available. 
Action:  Check  that  prolog  is  properly  installed  and  running. 

***  ZTT  OOOA  —  Data  base  attribute  errors. 

Meaning:  Some  or  all  of  the  required  attributes  for  TEA 
have  not  been  entered  for  the  current  graph. 

Action:  Edit  all  required  attributes  and  fill  in  the  appropriate 
values. 


***  ZTT  OOlW  —  Attribute  attr_value  missing  for  node  node. 

Meaning:  A  specific  attribute  is  missing  for  a  particular 
node. 

Action:  Edit  the  node  attribute  and  fill  in  the  appropriate  value. 

***  ZTT  002VV  —  Attribute  attr_value  missing  for  port  portj^. 

Meaning;  A  specific  port  attribute  is  missing  for  a  particular 
node. 

Action;  Edit  the  port  attribute  and  fill  in  llie  appropriate  vaiue. 
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***  ZTT  OOSW  —  Attribute  attrjualue  missing  for  arc  arcjname. 

Meaning:  A  specific  arc  attribute  is  missing  for  a  particular 
arc. 

Action:  Edit  the  arc  attribute  and  fill  in  the  appropriate  value. 

***  ZXX  001 A  —  Not  enough  memory. 

Meaning:  There  is  not  enough  memory  for  the  graph. 

Action:  Reduce  the  size  of  the  graph. 

***  ZXX  002W  —  Invalid  filename  extension  ext  on  file  file. 

Meaning:  The  extension  on  the  indicated  file  (e.g.,  .swg) 
is  invalid. 

Action:  Change  the  filename  extension. 

***  ZXX  003E  —  Can’t  access  template  file  name. 

Meaning:  The  file  name  does  not  exist  or  does  not  have  the 
appropriate  read/write  permissions. 

Action:  Check  for  the  file’s  existence  and  proper  permissions. 

***  ZXX  004E  —  Can’t  initialize  template  data  base. 

Meaning:  The  maximum  number  of  internal  data  bases  has  already 
been  reached. 

Action:  Contact  RTl  for  assistance. 
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ZXX  OOSE  —  Can’t  read  template  file  name. 

Meaning:  The  template  data  base  name  is  not  in  the  expected 
format. 

Action:  Contact  RTI  for  assistance. 

ZXX  006E  —  Premature  EOF  encountered  while  reading  template  file  name. 

Meaning:  It  is  likely  that  the  file  has  been  damaged  since 
part  of  the  data  is  missing. 

Action:  Recreate  the  file. 

ZXX  (X)7E  —  Not  enough  memory  to  read  in  template  file. 

Meaning:  There  is  not  sufficient  memory  to  create  an  internal 
template  data  base. 

Action:  Contact  the  local  ADAS  administrator. 

ZXX  OOSE  —  No  source  ports  for  arc. 

Meaning:  No  nodes  have  an  available  input  port. 

Action:  No  action  required. 

ZXX  009E  —  Error  in  reading  template  file  filename. 

Meaning:  There  was  an  error  in  reading  the  template  file. 

Action:  Try  again  with  the  same  or  different  file,  or  contact 

RTI  for  assistance. 
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***  ZXX  OlOW  —  No  template  file:  creating  new  template  data  base  name. 

Meaning:  A  template  data  base  is  being  created  for  the  new  subgraph  data  base. 
The  template  data  base  will  have  name  name. 

Action:  No  action  is  required. 

***  ZXX  01  lE  —  No  nodes  or  partitions  found  in  this  graph. 

Meaning:  There  is  no  node  or  partition  to  choose. 

Action:  No  action  is  required. 

***  ZXX  012E  —  No  buses  found  in  this  graph. 

Meaning:  There  is  no  bus  to  choose. 

Action:  No  action  is  required. 

***  ZXX  020E  —  No  filenames  defined. 

Meaning:  No  filename  is  listed  by  the  attribute  chosen. 

Action:  Check  attribute  value. 

***  ZXX  022E  —  The  file,  name,  does  not  exist. 

Meaning:  The  filename  listed  by  the  attribute  cannot  be 
found. 

Action:  Check  existence  of  file  and  read  access. 
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*** 


*** 


ZXX  023W  —  Nodes  with  the  same  attribute  value  for  name  have 
different  node  templates. 

Meaning:  More  than  1  node  matched  the  attribute  value  and 
they  have  different  templates. 

Action:  Correct  inconsistency. 

ZXX  024W  —  Default  filename  name  already  exists. 

Meaning:  A  file  with  the  default  name  value  exists. 

Action:  None  required. 

ZXX  025E  —  Graph  contains  no  nodes. 

Meaning:  No  nodes  found  in  graph  of  this  class 
specification. 

Action:  None  required. 

ZXX  026E  —  Invalid  node  class  for  name. 

Meaning:  A  node  must  have  a  class  of  value  (internal, 

leaf,  inport,  outport,  or  biport)  to  be  recognized. 

Action:  Check  class  value. 


ZXX  027E  —  name  is  not  a  valid  node  name. 

Meaning:  Name  is  not  a  valid  ADAS  node  name. 

Action:  Correct  the  entry  and  retry.  Check  the 
ADAS  User  Manual,  Version  2.3  or  later, 
for  correct  name  rules. 
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*** 


*** 


ZXX  028W  —  Error  allocating  memory. 

Meaning:  TEA  cannot  access  enough  memory. 

Action:  Contact  RTI  for  assistance. 

ZXX  029E  —  Graph  attribute  name  does  not  exist. 

Meaning:  This  graph  data  base  does  not  contain  attributes 
of  this  value. 

Action:  No  action  required. 

ZXX  030E  —  Unable  to  access  directory  name. 

Meaning:  Error  reading  directory. 

Action:  Check  name. 

ZXX  031E  —  No  extension  files  found. 

Meaning:  Error  creating  the  menu  of  files. 

Action:  Check  entry  and  retry. 
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1.  SCOPE 


1.1.  Identification.  This  Reference  Manual  provides  operational  information  for  users  of 
the  computer  software  configuration  item  (CSCI)  identified  as  the  Integration  of  Very 
High  Speed  Integrated  Circuit  (VHSIC)  System  Functional  Design  and  Design  for  Tes¬ 
tability  tools,  to  be  known  as  the  Test  Engineer’s  Assistant  (TEA)  system. 

This  document  should  be  used  in  conjunction  with  the  Software  System  User’s  Manual 
for  the  Test  Engineer’s  Assistant  system.  This  reference  manual  will  help  the  user 
prepare  input  for  the  TEA  tools;  the  User’s  Manual  will  aid  in  the  mechanics  of  the  use 
of  the  tools;  this  reference  manual  will  be  useful  in  the  analysis  of  the  outputs  of  the 
tools  and  the  direction  that  the  user  should  take  dependent  on  that  output. 

1.2.  Purpose.  The  Architecture  Design  and  Assessment  System  (ADAS)  provides  a 
graphic  schematic  capture  capability  to  VHSIC  designers.  TEA  provides  a  design 
automation  system  for  the  incorporation  of  design  for  test  (DFT)  and  built-in  test 
(BIT)  techniques  into  VHSIC  digital  hardware  described  using  ADAS  and  VHSIC 
Hardware  Description  Language  (VHDL).  TEA  provides  the  methodology  and  the  tools 
for  evaluating  proposed  designs  for  hard-to-test  digital  hardware  constructs,  for  recom¬ 
mending  alternative  constructs,  and  for  identifying  hierarchical  BIT  techniques  to 
increase  the  overall  testability  of  a  hardware  system.  TEA  aids  designers  at  the  board, 
subsystem,  and  system  levels.  TEA  estimates  the  costs  associated  with  the  BIT  tech¬ 
niques  to  allow  the  designer  to  make  informed  choices  about  BIT  incorporation.  A 
library  of  reusable  BIT  modules  supports  TEA  BIT  techniques  and  enables  the 
designer  to  simulate  the  entire  system  in  VHDL.  ADAS  provides  the  interface  to 
VHDL  from  the  graphic  connectivity  schematic. 

The  main  purpose  of  this  document  is  to  present  helpful  information  about  the  TEA 
methodology  of  testable  design,  the  purpose  and  use  of  the  TEA  tools  and  utilities, 
how  to  prepare  ADAS  graphs  for  use  with  the  TEA  tools,  and  the  library  of  reusable 
BIT  modules.  The  designers  of  the  system  have  identified  procedures  and  hints  for  use 
and  compiled  them  into  this  document. 

1.3.  Introduction.  This  Reference  Manual  contains  background  information  on  TEA, 
describes  the  TEA  design  methodology,  and  fully  documents  the  TEA  tools.  It  will 
instruct  in  the  use  of  the  tools  and  the  analysis  of  the  results.  An  example  will  be 
illustrated  and  demonstrated  in  the  final  section.  The  doppler  filter  card  of  the  signal 
processing  subsystem  of  the  Firefinder  Radar  system  is  used  as  an  example  of  the  use 
of  the  tools. 

1.4.  Background. 

1.4.1.  Army  Maintenance  Approach.  One  of  the  major  goals  of  the  Department  of 
Defense  is  the  implementation  of  a  2-level  maintenance  policy  for  next  generation 
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electronic  systems.  Broadly  speaking,  2-level  maintenance  is  performed  at  two  levels  of 
organization  or  two  locations,  usually  at  the  system  in  the  field  or  at  a  depot,  with 
essentially  no  maintenance  performed  at  any  other  level.  There  are  three  primary 
prerequisites  for  the  2-level  maintenance  concept  to  be  feasible. 

a.  The  line  replaceable  units  or  modules  should  have  high  mean  failure  time  and 
relatively  low  cost. 

b.  Fault  detection  and  isolation  must  largely  be  a  system-embedded  function  that 
is  comprehensive  and  free  of  false  alarms. 

c.  Line  replaceable  units  or  modules  should  be  modular  in  design,  easily  accessi¬ 
ble,  and  supportive  of  a  hierarchical  testability  approach. 

To  achieve  these  prerequisites,  a  system  must  be  implemented  using  highly  reliable 
components  and  integration  techniques,  and  testability/diagnosability  must  be  con¬ 
sidered  as  design  requirements  of  equal  importance  to  performance,  size,  and  cost.  To 
meet  testability/diagnosability  requirements  in  the  VHSIC  era,  within  the  2-level 
maintenance  constraints,  the  system  designer  has  to  rely  more  on  design  for  testability 
and  built-in  test  approaches  rather  than  external  Automatic  Test  Equipment  (ATE). 

Design  for  testability  and  built-in  test  approaches  exist  at  the  chip  and  board  levels. 
Unfortunately,  while  DFT  techniques  and  BIT  approaches  are  available  for  incorpora¬ 
tion  into  higher  levels  of  VHSIC  system  designs,  this  activity  is  not  methodical  and,  in 
most  cases,  is  separate  from  the  functional  system  design  process.  In  general,  testabil¬ 
ity  schemes  are  incorporated  into  the  design  after  the  functional  design  is  completed. 
This  practice  is  due  partly  to  the  lack  of  a  unified  system  design  for  testability  metho¬ 
dology  and  supporting  tools. 

1.4.2.  Advanced  CAD/E  for  Systems  Testability  fACST).  RTI  developed  a  generic, 
top-down  design  for  testability  methodology  that  results  in  improved  testability 
through  judicious  use  of  BIT  and  through  use  of  design  for  testability  at  different  lev¬ 
els  of  the  system  design  abstraction.  The  developed  design  methodology  is  supported 
by  a  BIT  implementation  scheme  to  achieve,  with  high  confidence,  fault  detection  and 
fault  isolation  to  a  predetermined  number  of  modules  (e.g.,  chips,  boards,  or  subsys¬ 
tems).  The  final  report  describes  alternative  approaches  for  using  BIT  at  the  board 
level  to  achieve  the  testability  required  to  isolate  a  fault  to  an  ambiguity  group  of 
chips.  Additionally,  an  implementation  of  a  board  level  BIT  technique  is  also 
described.  The  proposed  technique  uses  a  special  test  module,  designed  and  imple¬ 
mented  by  RTI,  that  performs  tests  on  ambiguity  groups  with  minimal  outside  inter¬ 
vention. 

Finally,  the  proposed  board  level  design  for  testability  methodology  was  demonstrated 
on  the  AN/TPQ-36  (Firefinder)  radar  system.  ADAS  was  used  to  obtain  a  hierarchical 
description  of  the  doppler  filter  section  of  the  signal  processor  to  verify  system  func¬ 
tionality  and  to  gain  insight  into  system  operation. 
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Testability  analysis  was  used  to  determine  the  ambiguity  group  sizes  of  the  board 
design  under  consideration,  as  well  as  the  mean  time  to  isolate  a  fault  in  these  ambi¬ 
guity  groups.  This  was  done  assuming  that  tests  are  applied  at  the  primary  inputs  of 
the  board  and  the  existing  test  points  on  the  board  are  only  monitoring  points  (i.e., 
not  control  points).  In  addition,  fault  simulations,  assuming  both  pin  level  and  gate 
level  classical  stuck-at  faults,  were  performed  to  determine  the  fault  coverage  one  can 
obtain  using  the  existing  design  with  test  vectors  provided  by  the  manufacturer. 

The  design  then  was  modified  to  meet  certain  ambiguity  group  size  requirements  that 
were  lower  than  what  the  testability  analysis  revealed  for  the  existing  design.  The 
new  design  was  performed  using  the  developed  design  methodology,  and  a  BIT  tech¬ 
nique  that  can  be  implemented  with  the  BIT  module  developed  by  RTI  was  recom¬ 
mended.  The  redesign  approach  taken  demonstrated  that  ambiguity  group  size  and 
mean  time  to  isolate  parameters  that  are  specified  as  design  requirements  can  be  met 
when  a  structured  DFT/BIT  methodology  is  used.  Furthermore,  fault  simulation 
results  demonstrated  that  the  fault  coverage  obtained  with  the  BIT  technique  used 
during  redesign  was,  in  general,  better  than  the  results  obtained  when  the 
manufacturer’s  test  sets  were  used. 

The  design  penalties,  in  terms  of  hardware  and  time  overhead  in  using  the  proposed 
BIT  technique,  were  also  presented  and  different  design  configurations  of  the  proposed 
test  module  were  discussed  with  a  goal  of  minimizing  the  design  penalty  for  different 
applications  with  varying  design  requirements. 

The  structured  design  methodology  provided  by  this  effort  allows  the  designer  of  Army 
systems  to  incorporate  testability  features  into  this  design  using  a  systematic 
approach,  thus  producing  systems  that  are  testable  by  construction.  The  single-chip 
test  module  developed  and  demonstrated  by  RTI  can  be  used  in  a  variety  of  board 
level  BIT  implementations  of  signature  analysis  that  can  cover  a  wide  range  of  applica¬ 
tions.  TEA  uses  this  module  in  an  example  implementation  of  a  BIT  technique  for  test 
pattern  application  and  resultant  data  compression. 

The  work  described  here  supplied  the  incentive  and  background  for  the  work  done  on 
TEA.  ACST  provided  the  start  for  the  TEA  methodology  development.  During  TEA, 
the  ACST  methodology  was  expanded  and  automated  to  meet  the  testability  goals 
defined  during  ACST.  This  methodology  will  be  described  in  Section  2. 

1.4.3.  Architecture  Design  and  Assessment  System  (ADAS).  A  well-integrated  set  of 
tools  is  the  key  to  improving  system  designer  productivity.  Tools  are  needed  to  sup¬ 
port  designers’  activities,  from  conceptualizing  the  system  to  completing  a  chip. 

ADAS,  developed  by  the  Center  for  Digital  Systems  Research  at  RTI,  is  an  integrated 
set  of  computer-aided  engineering  tools  which  supports  the  synthesis  and  analysis  of 
electronic  systems  in  several  ways.  During  synthesis,  ADAS  provides  an  interactive 
color  graphics  environment  for  creating  and  manipulating  high  level  hardware  and 
software  designs.  During  analysis,  ADAS  provides  detailed  simulation  results  and  per¬ 
formance  analysis  for  verifying  and  evaluating  the  design.  .ADAS  performs  consistency 
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checks  on  both  hardware  and  software  graphs.  ADAS  uses  both  simulation-based  and 
analytical  techniques  to  calculate  performance  characteristics.  ADAS  supports  top- 
down  design  and  bottom-up  analysis  of  systems.  A  common  data  base  integrates  the 
ADAS  tool  set,  supporting  the  synthesis,  analysis,  and  refinement  of  both  software  and 
hardware  at  high  levels  in  the  design  process. 

The  ADAS  graph  data  base  provides  the  necessary  attributes  and  structural  informa¬ 
tion  to  support  a  wide  range  of  simulation  tool  interfaces.  These  tools  build  functional 
simulators  from  ADAS  graphs  and  functional  module  descriptions  written  in  an  associ¬ 
ated  language.  A  current  contract  supports  the  addition  of  interfaces  to  the  VHDL 
tool  set.  For  access  to  ADAS  information  from  other  systems  the  ADAS  data  base 
library  provides  a  full  set  of  documented  data  base  access  routines. 

At  the  highest  system  levels,  ADAS  graphs  capture  an  operational  model  of  the  system 
architecture,  allow  successive  partitioning  of  software  and  hardware  tasks,  and  provide 
performance  information  including  software  and  hardware,  component  utilization, 
response  times,  and  potential  bottlenecks. 

In  an  effort  parallel  with  TEA,  RTI  has  been  working  to  integrate  ADAS  with  the 
DoD’s  VHDL  and  Silicon  Compiler  System’s  Genesil  software.  The  resulting  CAD  sys¬ 
tem  is  called  the  VSC  or  VHSIC  Silicon  Compiler.  Together,  the  three  components  of 
the  VHSIC  Silicon  Compiler  support  most  of  the  activities  required  to  design  working 
application-specific  integrated  circuits. 

At  the  highest  system  levels,  ADAS  graphs  capture  an  operational  model  of  the  system 
architecture,  allow  successive  partitioning  of  software  and  hardware  tasks,  and  provide 
narrative  information  on  system  functionality.  Performance  information  can  also  be 
obtained  on  component  utilization  and  load  balancing,  timing,  and  potential 
bottlenecks. 

Once  hardware  structure  has  been  determined,  modules  can  either  be  selected  from 
the  VHDL  library  or  custom  designed  when  necessary.  At  this  point,  VSC  can  provide 
estimates  of  chip  power  dissipation  area  and  pinout,  as  well  as  predict  system  perfor¬ 
mance  and  functional  correctness  based  on  the  selected  VHDL  modules. 

When  a  satisfactory  design  has  been  achieved,  the  component  and  connection  informa¬ 
tion  is  directed  to  Genesil  to  create  complete  fabrication  specification  information. 

The  design  checks  performed  by  Genesil  are  based  on  the  creation  of  five  chip  models: 
physical  layout,  power  dissipation,  function,  performance,  and  logic. 

Once  the  chip  layout  demonstrates  satisfactory  behavior,  a  pattern  generation  tape  is 
created  with  the  fabrication  process  specified  by  the  designer.  At  the  present  time, 
there  are  over  twenty  fabrication  processes  available  from  which  designers  may  choose. 

1.4.4.  VHSIC  Hardware  Description  Language  (VHDL).  VHDL  has  been  fostered  by  the 
Department  of  Defense  and  adopted  as  the  required  hardware  design  system  for  use 
with  VHSIC  technology.  VHDL  provides  a  standardized,  computer-a.ssisted  methodol¬ 
ogy  to  specify,  verify,  and  archive  hardware  designs. 
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VHDL  supports  the  design,  description,  and  simulation  of  hardware  from  a  behavioral 
level  down  to  the  gate  level.  A  design  environment  that  includes  support  tools  such  as 
a  syntax-checking  analyzer,  a  simulator,  and  a  design  library  has  been  developed  for 
the  Air  Force. 

ADAS  supports  simulation  in  VHDL  from  hierarchical  hardware  graphs.  TEA  provides 
VHDL  descriptions  of  BIT  modules  that  are  to  be  added  to  a  design  to  increase  testa¬ 
bility. 

1.4.5.  Tester  Independent  Support  Software  System  (TISSS).  TISSS  has  a  VHDL-to- 
fault  simulation  capability  which  TEA  needs  to  assess  the  value  of  its  recommenda¬ 
tions.  TISSS  is  currently  coded  to  handle  7.2  VHDL. 


2.  TEA  METHODOLOGY 


This  paragraph  describes  the  Test  Engineer’s  System  (TEA)  system,  including  the 
TEA  methodology  as  implemented  by  the  TEA  utilities  and  tools. 

To  aid  the  user,  Architecture  Design  and  Assessment  (ADAS)  tools  (e.g.,  EDIGRAF, 
the  ADAS  graph  editor)  will  be  shown  in  all  capital  letters,  and  functions  within  the 
tools  (e.g.,  edit)  will  be  shown  in  bold  typeface. 

The  user  is  directed  to  the  ADAS  User  Manual,  version  2.3  and  updates  including  the 
User  Manual  for  the  VHSIC  Silicon  Compiler  System  for  information  concerning  ADAS 
tools  besides  TEA. 

2.1.  TEA  System  Overview.  Utilization  of  the  TEA  system  methodology  and 
computer-aided  design  (CAD)  tools  enables  testable  digital  hardware  design  to  occur  in 
parallel  with  system  functional  design  and  results  in  systems  that  are  maintainable  at 
a  lower  life-cycle  cost. 

Design  for  testability  (DFT)  techniques  are  available  for  incorporation  into  the  board 
and  subsystem  levels  of  system  designs  and  TEA  provides  a  methodology  and  a  sup¬ 
porting  CAD  system  allowing  the  system  VHSIC  designer  to  meet  predefined  testabil¬ 
ity  requirements.  This  is  accomplished  by  supporting  DFT  and  built-in  test  (BIT) 
techniques  at  all  levels  of  design  abstraction. 

The  methodology  and  tools  support  the  concept  of  testable  boards  as  building  blocks 
of  testable  subsystems;  these  subsystems,  in  turn,  can  be  used  to  create  testable  sys¬ 
tems.  The  TEA  methodology  supports  design  for  testability,  choice  of  BIT  technique 
for  a  board,  which  is  also  supported  at  the  subsystem  and  system  levels,  and  augmen¬ 
tation  of  the  system  function  with  predefined  BIT  modules  to  increase  board  testabil¬ 
ity. 

Figure  2-1  depicts  a  system  design  methodology.  The  concurrent  functional  and 
testable  design  methodology  addresses  testability  issues  at  all  stages  of  systems  design 
(i.e.,  preliminary,  detailed,  final)  and  at  each  level  of  the  system  hierarchy.  As  shown 
in  Figure  2-1,  the  requirements  analysis  identifies  those  attributes  that  the  system 
must  meet.  During  preliminary  design,  hardware  resources  must  be  identified.  At  this 
stage  in  the  system  design  process  and  in  contrast  to  traditional  design  practices,  test 
resources  must  also  be  determined.  This  is  the  area  where  TEA  begins  to  have  an 
effect.  During  detailed  design,  the  specific  functionality  of  system  resources  must  be 
identified  and  verified  through  simulation  and  checked  against  system  requirements, 
including  testability.  Trade-offs  are  made  at  this  point  to  ensure  that  system  require¬ 
ments  are  met. 
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Figure  2-1.  The  System  Design  Methodology  Used  by  TEA 
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Figure  2-2.  The  User’s  Roadmap  Through  Detailed  Design  Using  the  TEA  Tools 
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As  noted  in  Figure  2-1,  the  TEA  system  is  primarily  used  to  support  the  detailed 
design  phase  of  the  methodology.  Figure  2-2  shows  the  steps  involved  in  using  the 
TEA  tools.  This  is  a  high-level  description;  however,  the  emphasis  on  design  process 
for  testable  boards  is  shown  as  iterative  loops  in  the  figure.  TEA  system  tools  are 
shown  in  parentheses.  i 

There  are  five  newly  developed  tools.  Design  for  Testability  Guideline  Checker  identi¬ 
fies  untestable  structures  and  recommends  alternative  structures  that  are  more 
testable.  BIT  Recommendation  divides  a  board  into  ambiguity  groups  for  fault  isola¬ 
tion  testing  and  recommends  a  class  of  BIT  techniques  for  each  ambiguity  group.  BIT 
Overhead  Summary  calculates  the  approximate  hardware  overhead  (i.e.,  BIT  support 
modules  and  additional  I/O)  associated  with  the  implementation  of  a  particular  board 
level  BIT  technique.  BIT  Placement  Recommendation  generates  a  new  schematic  of 
the  board  with  a  sample  implementation  of  the  given  technique.  The  three  comple¬ 
mentary  BIT  tools  are  shown  in  Figure  2-3.  System  Summary  itemizes  the  incremental 
hardware  overhead  attributable  to  added  testability. 


Figure  2-3.  TEA  BIT  Recommendation  Tools 
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The  TEA  user  does  not  need  to  capture  his  design  in  any  restricted  way.  TEA  does 
not  need  to  have  each  board  described  on  an  individual  graph  or  even  on  graphs  at  the 
same  level  of  ADAS  hierarchy.  TEA  does,  however,  assume  that  '‘leaf”  nodes  are  chips 
and  makes  recommendations  accordingly. 

Utilities  enable  the  user  to  add  his  own  guidelines  for  identifying  untestable  structures; 
to  select  special  ambiguity  groups;  and  to  obtain  on-line  help  about  user  functions,  tool 
data  bases,  and  tool  outputs.  TEA  provides  the  user  with  a  color  representation  or 
“current  view”  of  the  design  and  a  menu-oriented  user  interface.  These  tools  and  util¬ 
ities  will  be  discussed  in  detail  in  Paragraphs  2.6  and  2.7,  the  user  interface  in  2.5. 

The  TEA  system  accepts  an  .\DAS  schematic  of  the  system,  which  has  been  function¬ 
ally  verified  using  VHDL,  as  its  input.  After  BIT  has  been  added  to  the  system  using 
recommendations  from  the  TEA  tool,  the  TEA  methodology  supports  resimulation  of 
the  system  in  VHDL  with  the  added  BIT  features  and  test  modes  by  providing  VHDL 
descriptions  of  the  BIT  modules  (see  Paragraph  2.3.3)  and  by  instructing  in  the  use  of 
the  modules  under  normal  and  test  modes. 

tea’s  concept  of  a  testable  system  is  illustrated  in  Figure  2-4.  TEA  aids  in  the  design 
of  testable  boards  such  that  any  on-board  built-in  test  reports  to  an  on-board  mainte¬ 
nance  node  which  controls  test  application  and  reporting.  To  close  the  loop,  the 
maintenance  node  communicates  with  a  subsystem  test  control  unit  (TCU)  via  a  sub¬ 
system  test  bus  and  a  system  TCU  via  a  system  test  bus,  which  may  be  identical  in 
certain  applications.  The  system  TCU  may  communicate  with  automatic  test  equip¬ 
ment  (ATE)  to  receive  inputs  or  process  outputs. 

TCU  functions  include 

a.  self-diagnosis 

b.  initialize  and  control  the  test  of  boards/subsystems 

c.  interpret  test  results 

d.  communicate  test  results  to  system  TCU/ATE 

Depending  on  the  level  of  BIT  implemented  and  fault  detection/isolation  capability 
required,  automatic  test  equipment  may  or  may  not  be  needed  to  supplement  the  sys¬ 
tem  level  TCU.  TEA  recommends  each  of  the  features  shown  in  Figure  2-4,  but  its 
primary  function  is  leading  the  user  towards  testable  board  designs. 

TEA  handles  both  structured  and  unstructured  logic  within  the  same  environment; 
therefore,  the  design  can  contain  both  unique  and  off-the-shelf  components.  TEA  aids 
a  designer,  who  is  not  necessarily  a  test  expert,  to  meet  a  fault  isolation  requirement 
by  identifying  ambiguity  groups  (AGs)  (An  AG  is  the  smallest  interconnected  unit  to 
which  a  fault  can  be  isolated.)  which  have  heuristically  similar  test  characteristics. 
When  a  fault  is  isolated  to  an  AG,  then  all  components  of  an  AG  are  replaced  and 
testing  is  restarted.  Non-ambiguous  isolation  to  an  AG  can  minimize  the  cost  and 
time  of  parts  replacement. 
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Figure  2-4.  TEA’s  Hierarchical  View  of  a  System 
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2.2.  The  TEA  Workstation  and  Requirements.  The  workstation  on  which  TEA  was 
developed  and  delivered  is  a  DEC  VAXstation  II  with  GPX  graphics.  This  workstation 
uses  the  DEC  VMS  operating  system  version  4.6.  Some  of  the  TEA  tools  output 
graphical  information;  this  information  is  lost  if  the  user’s  monitor  does  not  support 
color.  The  DEC  C  compiler  version  2.3  was  used  to  prepare  the  code  for  delivery.  The 
user  needs  Quintus  Prolog  version  2.0  to  run  the  Design  for  Testability  Guideline 
Checker  and  to  add  any  guidelines  to  the  Design  for  Testability  Guideline  data  base. 
To  run  simulations  using  VHDL,  the  user  must  know  how  to  use  those  tools.  TEA 
supplies  a  BIT  support  module  library  written  in  both  version  7.2  VHDL  and  1076 
VHDL.  ADAS  supplies  a  tool  to  obtain  an  ADAS  template  from  a  IEEE  standard  1076 
VHDL  code  segment,  called  TEMPGEN.  VHDLGEN  generates  IEEE  standard  1076 
VHDL  code  for  a  simulation  from  IEEE  standard  1076  VHDL  code  segments  whose 
data  flow  is  represented  by  an  ADAS  hardware  graph. 

If  the  user  does  not  need  to  change  any  of  TEA,  then  he  just  needs  the  machine, 
operating  system,  compiled  TEA  code,  and  Prolog.  If  the  user  needs  to  produce  large 
AD  AS- VHDL  simulations  of  his  system,  a  larger  machine  is  recommended  for  that  por¬ 
tion  of  the  development.  If  speed  of  operation  is  a  concern,  a  larger  VAX  could  be 
used  for  the  C-oriented  portions  of  TEA  (This  excludes  the  Design  for  Testability 
Guideline  Checker,  which  is  written  in  Prolog.). 

The  user  of  TEA  is  not  expected  to  be  a  testing  expert,  but  is  assumed  to  be  a  system 
and/or  board  designer  competent  with  ADAS  and  its  data  base  structure.  A  working 
knowledge  of  EDIGRAF  is  necessary  to  capture  the  design  for  use  with  TEA.  The 
EDIGRAF  supplied  with  TEA  is  different  from  the  EDIGRAF  commercially  available 
currently  with  ADAS.  TEA’s  EDIGRAF  allows  buses  and  256  inports/outports/biports 
per  node.  The  user  is  directed  to  RTI  to  obtain  more  information  about  these 
features.  TEA  ignores  biports,  but  uses  buses.  The  user  is  strongly  encouraged  to  use 
ADAS  buses  instead  of  fanout  nodes  to  show  a  signal  propagating  to  multiple  destina¬ 
tions.  In  general,  TEA  will  give  unpredictable  results  if  fanout  nodes  are  used.  A  mes¬ 
sage,  is  given  at  the  start  up  of  TEA  if  fanout  nodes  are  detected. 

******Warning 

******This  graph  contains  fanout  nodes. 

******TEA  may  generate  unpredictable  results. 

******Buses  are  recommended  for  replacement  of  fanout  nodes. 
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2.3.  Inputs  to  TEA.  The  user  communicates  the  features  and  connectivity  mapping  of 
his  design  by  capturing  the  schematic  in  .\DAS  and  by  associating  appropriate  attri¬ 
butes  to  each  node  in  the  description.  Nearly  all  information  needed  by  TEA  is  held 
in  the  ADAS  data  base.  Exceptions  are  noted  in  Paragraph  2.3.4. 

2.3.1.  ADAS  Hardware  Graphs.  Just  as  other  ADAS  tools  operate  on  a  graphical 
representation  of  the  user’s  system,  called  a  graph,  TEA  needs  a  set  of  hierarchical 
hardware  graphs  from  which  to  draw  conclusions  about  the  testability  of  the  system. 
TEA  is  primarily  concerned  with  digital  circuit  boards,  but  there  is  no  inherent  reason 
why  the  design  for  testability  guidelines  (Paragraph  3.2)  could  not  be  extended  to  the 
non-digital  testability  arena,  if  graph  patterns  and  guidelines  could  be  identified.  Only 
synchronous  digital  BIT  techniques  are  supplied  with  TEA. 

To  identify  the  partitioning  of  syst.ms  into  subsystems  and  boards,  two  attributes  are 
assigned  to  each  node,  Tsubsystem  and  Tboard.  An  alphanumeric  string  is 
expected  in  each  of  these  to  uniquely  identify  each  node  with  a  particular  board.  All 
nodes  with  the  same  values  for  Tsubsystem  and  Tboard  are  assumed  to  reside  on 
the  same  board  and  should  be  considered  together  for  identifying  a  coherent  testability 
method  for  the  board. 

Other  information  about  a  node,  which  is  normally  a  representation  for  a  chip  at  the 
lowest  level  of  description,  is  communicated  via  the  node  and  port  attributes. 

2.3.2.  ADAS  Data  Base  Attributes.  Each  node,  bus,  and  arc  in  an  ADAS  graph  has 
attributes  attached  to  it.  Some  obvious  attributes  include  color,  width,  and  height. 

TEA  has  a  unique  set  of  node  and  arc  attributes  not  used  by  other  ADAS  tools.  These 
are  listed  here  along  with  a  table  of  particular  attribute  values  and  their  associated 
meaning  to  the  TEA  tools.  These  values  are  very  specific,  but  the  case  is  ignored.  All 
TEA  attributes  begin  with  a  capital  ‘T’. 

To  make  these  attributes  “visible”  to  EDIGRAF  and  TEA,  the  save  status  must  be  set 
to  “S”  using  the  edit  command.  Not  all  TEA  tools  need  each  of  the  attributes,  but  all 
are  necessary  for  the  accurate  completion  of  the  methodology.  There  is  a  checker  run 
at  the  initiation  of  TEA  to  make  sure  the  attributes  are  in  the  data  base  (they  do  not 
have  to  have  values). 

Note:  Each  node  should  have  been  assigned  to  a  uniquely  named  board  and  subsys¬ 
tem.  There  is  no  check  for  this,  but  board  names  must  a'l  be  unique  --  even  across 
subsystems.  One  of  the  tools  to  be  described  below  can  be  called  on  multiple  subsys¬ 
tems  simultaneously  and  if  two  boards  are  named  with  the  same  name,  an  unresolved 
command  interpreter  conflict  arises  and  unexpected  results  occur.  Identical  subsystem 
names  result  in  the  tool  understanding  that  there  is  only  one  subsystem  (with  that 
name)  and  all  boards  assigned  to  it  belong  to  the  one  subsystem.  Board  and/or  sub- 
•system  names  can  not  be  left  blank,  as  “null”  is  not  a  valid  value  (it  would  be  imprac¬ 
tical  to  select  a  “”  from  the  menu).  The  board  and  subsystem  names  of  leaf  nodes 
have  precedence  over  internal  nodes,  TEA  supports  the  concept  of  .ADAS  buses,  but 
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all  buses  are  assumed  to  be  a  single  bit  in  width.  Most  of  the  TEA  tools  work  on  ''flat¬ 
tened”  graphs-  Hierarchy  is  lost  and  “fanout”  node  (and  bus)  connectivity  becomes 
transparent.  (A-iain.  fanout  nodes  are  not  recommended.)  TEA  ignores  biports. 

Further  notes  on  buses:  since  buses  are  a  new  feature  to  even  the  most  expert  .ADAS 
users,  a  few  points  need  to  be  made.  An  ADAS  bus  does  not  represent  a  protocol  or 
directionality.  An  ADAS  bus  is  a  way  to  connect  multiple  inports/outports/biports  of 
multiple  nodes  together.  For  instance,  a  “clear”  signal  generated  by  one  node  can  be 
“bussed”  to  every  flip-flop  on  the  board  without  the  need  for  the  outdated  “fanout” 
node  concept.  Each  instance  receives  an  identical  copy  of  the  original  signal. 

ADAS  buses  can  have  multi-bit  widths,  but  TEA  assumes  that  a  bus  represents  a  sin¬ 
gle  bit. 

-ADAS  buses  must  have  at  least  one  input.  If  a  bus  has  no  input,  it  is  ignored,  and 
TEA  may  give  inaccurate  results. 

For  accurate  results,  TEA  users  should  label  any  pertinent  arc  attributes  on  the  arcs 
that  provide  input  to  the  bus.  For  example,  if  a  test  point  is  provided  on  a  bus,  an 
input  arc  to  the  bus  should  have  its  Tdft_io  attribute  set  to  test_point.  If  only  out¬ 
put  or  sink  arcs  are  labeled,  TEA  may  give  inaccurate  results.  If  two  or  more  input  or 
source  arcc  to  a  bus  are  primary  inputs,  they  should  each  have  their  Tdft_io  set  to 
primary  input. 

An  ADAS  bus  cannot  be  directly  connected  to  another  .ADAS  bus.  Watch  out  for  this 
when  subgraphs  are  created. 

Table  2-1  shows  all  TEA  attributes.  Table  2-2  shows  valid  syntax  for  the  TEA  attri¬ 
butes. 


Node  attribute 

Tag_naine 

Tag_test 

Tag_test_time 

Tasynch 

Tbit 

Tboard 

T  chip_maxfan 

Tconfig 

Tcount_bits 

Tdevice_type 

Tfault_cov 

Tgroup 

Thw  modale 

Tlogic_famiIy 

Tlogictype 


Table  2-1.  Meaning  of  Each  TEA  Attribute 
Meaning 

set  by  BRT,  name  of  the  AG  to  which  this  chip  belongs 

set  by  BRT,  AG  test  scheme 

time  or  test  vectors  needed  to  test  this  AG 

does  the  user  intentionally  use  this  chip  asynchronously? 

is  this  a  node  that  contributes  to  the  BIT? 

to  which  board  does  the  node  belong? 

max  lines  to  which  any  output  can  be  connected 

set  by  BRT,  holds  name  of  specific  scan  configuration 

how  many  bits  in  this  counter? 

analog,  digital,  mix 

user-provided  fault  coverage  for  Ttest_len  vectors 
set  by  BRT,  node  grouping  scheme 
number  of  gates  of  node 

to  what  logic  family  is  the  node's  I/O  compatible? 
combinational,  secpiential 
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Tnodejspectype 

Tnode_type 

Tscan 

Tselftest 

T  sp_ag_name 

Tstates 

Tsubsystem 

Ttest 

Ttest_len 

Ttri  state 


specific  device  type 
general  type  of  node 
is  this  chip  scannable? 
is  this  chip  self  testable? 

name  of  the  “special”  AG  to  which  this  chip  belongs 

number  of  single-bit  memory,  not  including  RAM/ROM 

to  which  subsystem  does  the  node  belong? 

set  by  BRT,  node  test  scheme 

number  of  user-provided  test  vectors 

is  chip  tristateable? 


Arc  attribute 

Tarc_type 
Tdftjo 
Ta  d 


Meaning 

data/ control  /  clock 

is  this  a  primary  I/O  or  test  point? 

is  this  an  analog  or  digital  signal? 


AG:  ambiguity  group 

BRT:  Bit  Recommendation  Tool 


Table  2-2.  Valid  Syntaxes  for  Each  Attribute 


Node  attribute 

Tagname 

Tag_test 

Tagtesttime 

Tasynch 

Tbit 


Tboard 
Tchip_inaxf  ‘n 

Tconfig 

Tcount_bits 

Tdevice_type 


Syntax _ 

Alphanumeric 
Alphanumeric 
Integer 
Default  =  0 
Alphanumeric 

Affirmative  =  async,  asynch,  asynchronous,  y,  yes 

Alphanumeric 

BIT  scheme  =  ps,dt 

Maintenance  Node  =  mn,  m_n,  maintenance 

BIT  Support  Node  =  bit_dt,  bit_ps 

Node  with  BIT  =  deterministic,  dt,  ps,  pseudorandom 

scan  support  modules  =  bit,  yes 

Alphanumeric 

Integer 

Default  =  0 

Alphanumeric 

Integer 

Default  =  0 

Alphanumeric 

Recognized  options  =  a,  analog,  d.  digital,  mix 
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Default  =  digital 

Tfault_cov 

Integer  (1  -  100) 

Special  case  =  100  means  “adequate  coverage" 

Default  =  0 

Tgroup 

Alphanumeric 

Thw  module 

Integer 

Tlogic_family 

Alphanumeric 

Recognized  options  =  emos,  eel,  gaas,  iil,  nmos,  ttl,  other 

Tlogic_type 

Alphanumeric 

Recognized  options  =  comb,  comb_logic,  combinational 
Default  =  sequential 

Tnode_spec_type 

Alphanumeric 

Tnode_type 

Alphanumeric 

Tscan 

Alphanumeric 

Recognized  options  =  etm,  etm_sup,  jtag,  jtagjsup,  vhsic, 
vhsicjsup,  scan,  scannable,  y,  yes 

Tselftest 

Alphanumeric 

Affirmative  =  bist,  bit,  self,  selftest,  vhsic,  y,  yes 

Tsp_ag_name 

Alphanumeric 

Tstates 

Integer 

Default  =  0 

Tsubsystem 

Alphanumeric 

Ttest 

Alphanumeric 

Ttest_len 

Integer 

Default  =  0 

Ttrijstate 

Alphanumeric 

Affirmative  =  tri,  tristate,  y,  yes 

Default  =  not  tristateable 

Arc  attribute 
Tarc_type 


Tdft  io 


Ta  d 


Syntax 


Alphanumeric 
Recognized  options 
Recognized  options 
Default  =  data 
Alphanumeric 
Recognized  options 
Recognized  options 
Recognized  options 
Alphanumeric 

Recognized  options  =  a,  analog,  d,  digital 
Default  =  digital 


elk,  clk_gen,  clock,  clock_generator 
cntrl,  control,  Ctrl,  d,  data 


pi,  po,  primary_input,  primary_output 
tp,  test_point 

tpo,  test_point_output,  test_pt_output 
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In  EDIGRAF  or  TEA,  the  edit  command  will  allow  the  user  to  view  and/or  change  the 
value  for  an  attribute.  Stats  on  a  node  will  allow  the  user  to  view  attribute  values. 

Besides  connectivity,  TEA  uses  attribute  values  to  decide  how  to  handle  a  node  in  a 
given  situation.  Attributes  provide  valuable  insight  into  the  function  and  purpose  of  a 
node.  Since  TEA  tries  to  evaluate  schematics  from  just  this  topological  information, 
completing  attribute  values  accurately  is  extremely  important  for  accurate  tool  results. 

If  attributes  are  not  assigned,  not  assigned  completely,  or  not  assigned  with 
proper  syntax,  the  tools  will,  in  general,  give  unpredictable  results.  Following 
are  lists  of  attributes  that  should  be  completed  for  acceptable  results  from  the  given 
tools. 


Table  2-3.  Attributes  and  Syntax  Needed  for 
Design  for  Testability  Guideline  Checker 


Node  Attribute 

Rule 

Meaning 

inport_id 

gl_01 

clear,  clr,  pre,  preset 

gl  02 

clear,  clr,  pre,  preset 

gl_03 

dsel,  dselect,  strobe 

gl_04 

tctrl,  trictrl 

gl_05 

enable,  hold 

gl  06 

add_latch_en,  address_latch_enable,  ale,  chip_sel,  chipjselect 

gl  06 

cs,  rd,  read,  read_write,  readwrite,  rw,  wr,  write 

gl_07 

bus,  bus_control,  bus_ctrl,  bus_node,  busnode,  Ctrl,  cntrl, 
control 

gl  14 

elk,  clk_gen,  clock,  clock_generator 

g2_03 

clock,  elk,  clk_gen,  clock_generator 

nodename 

all  rules 

alphanumeric 

outport_id 

all  rules 

alphanumeric 

g2  01 

elk,  clk_gen,  clock,  clock_generator 

g2_03 

carry,  carry_out,  co 

Tboard 

all  rules 

alphanumeric 

Tchipmaxfan 

g2  05 

Integer 

Tcountbits 

g2  03 

integer 

Tdevice_type 

gl  12 

a,  analog,  d,  digital 

gl_13 

a,  analog,  d,  digital 

Tlogic_family 

g2  04 

ttl,  ill,  eel,  emos,  nmos,  gaas,  other 

Tlogic_type 

gl  07 

combinational,  comb,  comb_logic 

gl_08 

combinational,  comb,  comb_logic 

Tnode_spec_type 

gl  09 

alphanumeric 

Tnode_type 

gl  01 

count,  counter,  ctr,  ff,  nip_flop,  flipflop, 

gl  01 

reg,  register,  shift_register,  shiftregister,  sr 

gl  02 

counter,  ctr,  ff,  flip_flop,  flipflop. 
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gl  02 

shift_register,  shiftregister.  sr,  reg,  register 

gl  03 

multiplex,  multiplexer,  multiplexor,  mux 

gl_05 

microprocessor,  u_proc,  up,  uproc,  processor 

gl_06 

dram,  fifo,  mem,  memory,  prom,  sram,  ram,  rom 

gl_07 

bus,  bus_control,  bus_ctrl,  bus_node,  busnode,  Ctrl,  cntrl, 
control 

gl  10 

fanout,  copy,  null 

gl_13 

da,  data_acquisition,  mix 

gl  14 

elk,  clk_gen,  clock,  clock_generator 

gl_16 

one_shot,  oneshot 

g2  01 

elk,  clk_gen,  clock,  clock_generator 

g2_03 

counter,  ctr,  count 

g2  05 

fanout,  copy,  null 

g2_06 

dram 

Tsubsystem 

all  rules 

alphanumeric 

Ttri_state 

gl_04 

tri,  tristate,  y,  yes 

gl_ll 

tristate,  tri,  y,  yes 

Tasych 

gl  14 

asynchronous,  y,  yes,  async,  asynch 

Arc  Attribute  Rule 
Tarc_typ€  gl_14 

Ta_d  gl_12 

gl_13 


Syntax 

elk,  clk_gen,  clock,  clock_generator 
a,  analog,  d,  digital 
a,  analog,  d,  digital 


Table  2-4.  Attributes  Used  by  Design  for  Testability  Guideline 
Checker  to  Determine  Primary  Input  Controllability 


Node  Attribute 

Tnodetype 

Tlogic_type 

Tboard 

Tsubsystem 


Syntax 

scan,  scannable,  scan_reg,  scan_register,  hi,  lo, 
gnd,  one,  vdd,  vec,  ves,  vss,  zero,  ground,  constant 
comb,  combinational,  comb_logic 
alphanumeric 
alphanumeric 
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Arc  Attribute  Syntax 
Tarc_type  d,  data,  Ctrl,  cntrl,  control 
Tdft_io  pi,  primary _input,  po,  primary_output,  tp,  tpo, 

test_point,  test_pt_output,  test__point_output 


Table  2-5.  Attributes  Used  by  Design  for  Testability  Guideline 
Checker  to  Determine  Primary  Output  Observability 


Node  Attribute 

T board 

Tlogic_type 

Tnodetype 


Tsubsystem 


Syntax 

alphanumeric 

comb,  combinational,  comb_logic 

scan,  scannable,  scan_reg,  scan_register,  ff, 

flip_flop,  flipflop,  ctr,  count,  counter,  reg,  register, 

shift_register,  shiftregister,  sr  . 

alphanumeric 


Arc  Attribute  Syntax 
Tarc_type  d,  data,  Ctrl,  cntrl,  control 
Tdft_io  pi,  primaryjnput,  po,  primaryjoutput,  tp,  tpo, 

test_point,  test_pt_output,  test_point_output 


Table  2-6.  Node  Attributes  Set  by  BIT  Recommendation  Tool  (BRT) 


Attribute 

Tagjname 

Tag_test 

Tconfig 

Tgroup 

Ttest 


Meaning 

set  by  BRT,  name  of  the  AG  to  which  this  chip  belongs 
set  by  BRT,  AG  test  scheme 

set  by  BRT,  holds  name  of  specific  scan  configuration 
set  by  BRT,  node  grouping  scheme 
set  by  BRT,  node  test  scheme 


2-14 


Node  Attribute 

inport_id 

output_id 

node_name 

Tasynch 

Tbit 

Tboard 

Tdevice_type 

Tfaultjcov 

Thw_module 

Tlogic_faniily 

Tlogictype 

Tnode_spec_type 

Tnodetype 

Tscan 

Tselftest 

Tsp_ag_name 

Tstates 

Tsubsystem 

Ttest  len 


Table  2-7.  Attributes  Needed 
for  BIT  Recommendation  Tool  (BRT) 

Meaning 

label  for  the  input  port  of  an  ADAS  node 
label  for  the  output  port  of  an  ADAS  node 
name  of  ADAS  node 

does  the  user  intentionally  use  this  chip  asynchronously? 
is  this  a  node  that  contributes  to  the  BIT? 
to  which  board  does  the  node  belong 
analog,  digital,  mix 

user-provided  fault  coverage  for  Ttest_len  vectors 
number  of  gates  of  node 

to  what  logic  family  is  the  node’s  I/O  compatible? 

combinational,  sequential 

specific  device  type 

general  type  of  node 

is  this  chip  scannable? 

is  this  chip  self  testable? 

name  of  the  “special”  AG  to  which  this  chip  belongs 
number  of  single-bit  memory,  not  including  RAM/ROM 
to  which  subsystem  does  the  node  belong? 
number  of  user-provided  test  vectors 


Arc  Attribute  Meaning 
Tarc_type  data/control/clock 

Tdftjo  is  this  a  primary  I/O  or  test  point? 

Ta_d  is  this  an  analog  or  digital  signal? 


Table  2-8.  Attributes  Needed  for  BIT 
Overhead  Summary  and  BIT  Placement  Recommendation 


Node  Attribute 

node_name 

Tag_naine 

Tboard 

Tnodetype 

Tsp_ag_name 

Tsubsystem 


Meaning 

name  of  ADAS  node 

set  by  BRT,  name  of  the  AG  to  which  this  chip  belongs 
to  which  board  does  the  node  belong 
general  type  of  node 

name  of  the  “special”  AG  to  which  this  chip  belongs 
to  which  subsystem  does  the  node  belong? 
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Arc  Attribute  Meaning 

Tdft_io  is  this  a  primary  I/O  or  test  point? 


Table  2-9.  Attributes  Needed  for  System  Summary 


Node  Attribute 

node_naine 

Tag_name 

Tag_test_time 

Tbit 

T board 

Tfault_cov 

Tsp_ag_name 

Tsubsystem 

Ttest  len 


Meaning 

name  of  ADAS  node 

set  by  BRT,  name  of  the  AG  to  which  this  chip  belongs 
time  or  test  vectors  needed  to  test  this  AG 
is  this  a  node  that  contributes  to  the  BIT? 
to  which  board  does  the  node  belong 
user-provided  fault  coverage  for  Ttest_len  vectors 
name  of  the  “special”  AG  to  which  this  chip  belongs 
to  which  subsystem  does  the  node  belong? 
number  of  user-provided  test  vectors 


Arc  Attribute  Meaning 
Tarc_type  data/control/clock 

Tdft_io  is  this  a  primary  I/O  or  tesi  pv.-jnt? 

Ta_d  is  this  an  analog  or  digital  signal? 


2.3.3.  VHDL  Descriptions  of  ADAS  Nodes.  ADAS  provides  a  facility  for  functional 
simulation  of  a  system  using  VHDL.  ADAS  will  provide  the  VHDL  code  of  an  entire 
system  given  the  code  segment  for  each  node/module  in  a  graph  and  the  graph 
describing  the  connectivity  of  the  modules.  VHDLGEN  uses  attribute  entity _name 
to  find  the  entity  description  for  a  node  and  arch_naine  for  the  architecture  body  for 
that  node. 

TEMPGEN,  another  ADAS  utility,  creates  an  ADAS  node  template  from  a  VHDL  code 
segment.  An  entity  description  file  is  used  as  input  and  a  hardware  template  data 
base  is  created.  EDIGRAF’s  merge  function  can  be  used  to  get  all  the  necessary 
hardware  templates  into  a  single  template  data  base  for  TEA. 

The  TEA  methodology  encourages  users  to  have  a  functionally  correct  description  of 
their  system  before  entering  TEA  so  that  when  TEA  has  completed  its  task  of  suggest¬ 
ing  changes  to  improve  testability  the  user  has  a  functionally  correct  target  to  bench¬ 
mark.  TEA  provides  a  library  of  built-in  test  support  modules,  including  pseudoran¬ 
dom  test  pattern  generators,  built-in  logic  block  observers,  and  scannable  registers, 
that  could  be  placed  in  an  ADAS  hardware  graph  to  implement  a  particular  technique. 
The  BIT  tools  know  about  these  modules  and  use  them  to  implement  the  BIT  tech¬ 
niques  which  are  known  to  the  system.  So  that  the  user  can  resimulate  his  system  for 
functional  correctness,  TEA  provides  VHDL  code  segments  and  ADAS  templates  for 
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each  of  these  modules. 

This  manual  is  not  intended  to  instruct  in  the  use  of  VHDL  or  ADAS  utilities  other 
than  those  used  in  TEA.  Other  supplemental  reference  materials  are  required  for  this. 

2.3.4.  User  Information  via  AOdS  Logicals.  There  are  two  very  specific  instances 
where  additional  information  is  provided  to  TEA  outside  the  ADAS  data  base. 

When  the  user  wants  to  add  his  own  design  for  testability  guidelines  to  those  known 
by  the  Design  for  Testability  Guideline  Checker  (Paragraph  2.7.1),  he  must  set  a  logi¬ 
cal,  tea_rules,  to  point  to  the  file  that  contains  the  names  of  the  available  guidelines, 
one  per  line. 

When  the  user  wants  to  provide  information  about  specific  integrated  circuits  for  the 
BIT  Recommendation  (Paragraph  2.7.2)  tool  to  use  in  making  decisions  about  how  to 
group  chips  into  ambiguity  groups,  he  must  set  a  logical,  tea_brt,  to  point  to  a  file 
that  contains  the  name  of  the  file  where  the  library  resides.  The  format  and  further 
information  concerning  this  file  is  found  in  Paragraph  2.7.2. 

2.4.  TEA  Output.  TEA  is  a  knowledge-based  system  that  tries  to  match  graphs  against 
patterns  known  to  inhibit  testability.  TEA  will  not  try  to  work  “behind  the  user’s 
back”  and  change  the  user’s  schematic  because  an  arbitrary  pattern  was  matched. 
Rather,  TEA  will  inform  the  user  via  output  reports  that  certain  configurations  had 
been  noted  in  the  schematic  and  that  the  user  has  the  option  to  do  something  about 
these  features  so  that  testability  will  be  increased. 

In  later  paragraphs,  the  specific  tools  will  be  described  along  with  the  output  reports 
because  this  is  TEA’s  primary  means  of  disseminating  information  to  the  user.  This  is 
a  design  feature  that  affords  the  user  flexibility  and  input  into  the  solution  of  any  tes¬ 
tability  inhibitors.  TEA  is  not  designed  to  be  an  arbitrator,  but  as  a  checklist  for 
adherence  to  known  “good”  testability  guidelines.  It  is  hoped  that  this  method  of  gui¬ 
dance  will  encourage  cleverness  on  the  part  of  the  designer/test  engineer  rather  than 
strict  conformity  to  rules. 

The  only  tool  that  has  an  option  to  change  a  user’s  graphs  is  the  BIT  Placement 
Recommendation  tool,  and  then  no  change  will  be  made  to  any  graph  except  at  the 
option  of  the  user.  BIT  Placement  Recommendation  will  add  BIT  support  modules  to 
a  user’s  design  to  support  an  implementation  of  an  on-board  BIT  technique. 

This  philosophy  applies  not  only  to  the  graphical  version  of  the  schematic,  but  to  the 
data  base.  TEA  will  only  change  data  base  attributes  as  necessary  to  communicate 
from  one  tool  to  another.  For  instance,  BIT  Recommendation  will  fill  in  the  node 
attributes  that  indicate  the  ambiguity  group  to  which  the  node  has  been  assigned  and 
how  that  ambiguity  group  is  to  be  tested. 

TEA  is  designed  to  keep  the  user  as  well  informed  as  possible.  The  on-line  help  infor¬ 
mation  system  is  driven  by  the  “position”  of  the  user  in  the  menu  hierarchy.  This  is 
tea’s  attempt  to  “keep  a  finger  in  the  right  place  in  the  manual”  for  the  user.  The 


2-17 


written  documentation  is  designed  to  supplement  and  expand  on  the  on-line  informa¬ 
tion. 

2.5.  The  TEA  User  Interface.  TEA  provides  the  user  with  a  color  schematic  or  “current 
view”  of  the  design  and  a  menu-oriented  interactive  user  interface,  which  is  identical 
to  the  ADAS  user  interface.  The  user  is  prompted  for  choices  at  each  step  of  the  pro¬ 
cess  and  the  user  either  chooses  menu  options  from  the  graphics  display  with  the 
mouse  or  types  in  his  selection  (only  as  many  letters  as  necessary  to  uniquely  identify 
the  selection)  at  his  keyboard.  Many  of  the  menu  selection  items  on  the  TEA  top-level 
menu  are  identical  to  EDIGRAF  options.  Refer  to  the  Software  System  User  Manual 
for  TEA  for  more  details  on  menu  options. 

As  in  ADAS,  TEA  users  communicate  with  the  data  base  through  tools  and  utilities 
attached  to  the  user  interface.  The  user  interface  formats  all  requests  and  inquiries  of 
the  data  base  and  receives  all  responses  from  the  data  base.  As  the  user  answers 
inquiries,  the  user  is  prompted  for  more  Information  needed  to  invoke  a  tool  or,  finally 
the  tool  is  invoked.  When  an  action  has  been  completed,  process  control  is  returned  to 
the  top-level  TEA  menu  and  another  action  can  be  initiated. 


2.6.  The  TEA  Utilities.  Utilities  enable  the  user  to  view  and  print  output  reports,  to 
select  special  ambiguity  groups,  and  to  obtain  on-line  help  about  user  functions,  tool 
data  bases,  and  tool  outputs. 

For  the  following  discussion,  menu  selections  and  attributes  (start  with  "T”)  are 
shown  in  boldface  type.  Unless  otherwise  stated,  program  control  is  returned  to  the 
user  interface  and  the  TEA  top-level  menu  at  the  completion  of  the  program's  execu¬ 
tion. 

2.6.1.  Ambiguity  Group  Names  (ag  name).  The  Ambiguity  Group  Names  (ag_naine) 
TEA  utility  has  three  functions: 

a.  to  check  connectivity  of  ambiguity  groupings. 

b.  to  access  the  ambiguity  group  name  of  any  node  as  input  to  the  BIT  Overhead 
Summary  and  BIT  Placement  Recommendation  tools.  The  user  may  view  and 
edit  these  groups. 

c.  to  maintain  a  list  of  special  ambiguity  groups  as  input  to  the  BIT  Recommen¬ 
dation,  BIT  Overhead  Summary,  and  BIT  Placement  Recommendation  tools. 
The  user  may  view,  add,  and  edit  these  groups. 

2. 6. 1.1.  Connectivity  Check  (conn  check). 

Conn_check  is  a  validity  check  for  ambiguity  groups.  All  nodes  in  a  valid  ambiguity 
group  must  be  directly  connected.  Conn_check  is  automatically  called  by  both 
reg_ag  and  spcl_ag. 

If  nodes  in  an  ambiguity  group  are  not  connected,  then  it  will  be  very  difficult  to  test 
those  nodes  as  a  group,  and  it  will  be  extremely  difficult  to  isolate  faults  to  the  group. 
If  the  user  finds  that  the  groups  he  has  selected  are  unconnected,  he  should  consider 
multiple  groups  or  consider  adding  intermediary  nodes  to  the  group  to  maintain  con¬ 
nectivity. 

This  utility  should  be  run  each  time  the  user  alters  the  grouping  of  a  board’s  nodes. 
The  BIT  Recommendation  Tool  will  only  recommend  groupings  of  nodes  connected  via 
data  paths. 

Inputs. 

The  user  inputs  the  board  and  subsystem  of  interest  via  the  user  interface. 

Processing. 

This  paragraph  contains  a  high-level  description  of  the  process  called  conn_check. 
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get  nodes  on  Tboard  and  Tsubsystem 
find  all  ambiguity  groups 
check  connectivity  of  each  group 
output  message 
if  ok 

issue  “no  error”  message 
if  not  ok 

issue  “error”  message 

Limitations. 

ADAS  data  base  graphs  must  have  been  previously  created  before  TEA  is  entered. 
Biports  are  ignored. 

TEA  supports  the  concept  of  ADAS  buses,  but  all  buses  are  assumed  to  be  a  single  bit 
in  width. 

Conn_check  works  on  a  “flattened”  graph  so  attributes  set  on  non-leaf  nodes  will  be 
ignored.  Attributes  assigned  to  “fanout”  nodes  will  also  be  disregarded. 

Outputs. 

Conn_check  will  issue  a  message  to  indicate  whether  it  found  errors  or  not. 

Conn_check  will  create  an  output  report  using  the  report  generator.  The  following  is 
a  sample  output  report  from  conii_check.  The  standard  header  is  shown  here,  but 
will  not  be  repeated  in  further  example  output  reports  for  the  sake  of  brevity. 

The  standard  header  shows  the  date  and  time  of  creation,  the  user,  the  graph  name, 
the  data  base  filename,  and  the  output  report  name.  The  body  of  the  report  shows 
that  an  error  in  choosing  ambiguity  group  “foo”  has  occurred.  The  user  needs  to 
select  nodes  which  are  connected  by  some  direct  path  to  form  an  ambiguity  group. 
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Test  Engineer’s  Assistant  (TEA)  Output  Report 

ADAS/TEA  Version:  PROTO.TYPE 
Research  Triangle  Institute 
P.O.  Box  12194 

Research  Triangle  Park,  NC  27709 

Date/Time:  Thu  Oct  15  09:04:35  1987 

User:  JJH 

Graph: 

Current  View  Graph:  Avionic_System_Hardware 

Current  View  Filename:  system. hwg 

Output  Report  Filename  =  ag_name01.rpt 


AMBIGUITY  GROUP  NAMES 
(ag_name  conn_check) 

AG  ‘foo’  containing  the  following  nodes  is  not  connected 
n3 
nlO 

ag_name  conn_check  completed 


Error  Message /Action. 

TEA  will  allow  the  user  to  continue  even  if  unconnected  groups  exist.  The  user  should 
carefully  consider  the  results  of  this  action. 

Additional  Information. 

See  paragraph  describing 

a.  report  generation  (Paragraph  2.6.2) 


2. 6.1. 2.  Regular  Ambiguity  Groups  (reg  ag). 

The  purpose  of  reg_ag  is  to  allow  the  user  to 

a.  conveniently  view  nodes  which  are  in  regular  ambiguity  groups 

b.  edit  the  Tag_name  of  any  node  assigned  to  a  regular  ambiguity  group 

The  Tag_name  attributes  are  assigned  by  the  BIT  Recommendation;  reg_ag  influ¬ 
ences  the  BIT  Overhead  Summary  and  BIT  Placement  Recommendation  tools  by 
allowing  changes  to  the  output  of  BIT  Recommendation.  The  user  may  assign  nodes 
from  special  ambiguity  groups  to  regular  ambiguity  groups,  further  affecting  the  out¬ 
put  of  BIT  Recommendation.  Conn_check  is  automatically  called  at  the  completion 
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of  reg  ag. 

Inputs. 

The  board  and  subsystem  are  input  to  reg_ag.  The  user  must  input  the  ambiguity 
group  to  be  edited.  The  next  menu  shows  all  nodes  on  the  board.  Those  that  are 
currently  assigned  to  the  regular  ambiguity  group  are  shown  in  one  color  (yellow),  ones 
assigned  to  special  ambiguity  groups  are  shown  in  another  (magenta),  those  assigned  to 
other  regular  ambiguity  groups  are  shown  in  a  third  (orange),  and  all  others  are  shown 
in  white. 

Each  ambiguity  group  on  a  board  has  a  unique  name.  If  the  ambiguity  group  is  “regu¬ 
lar”  (i.e.,  assigned  by  BIT  Recommendation),  the  name  is  stored  in  Tag_name.  If  the 
ambiguity  group  is  “special”  (i.e.,  assigned  by  the  user),  the  name  is  stored  in 

Tsp_ag_name. 

The  Tag_name  attribute  of  each  node  assigned  to  an  ambiguity  group  is  updated  to 
reflect  the  ambiguity  group  name.  If  a  special  ambiguity  group  node  is  switched  to  a 
regular  ambiguity  group,  the  Tsp_ag_name  attribute  is  cleared  and  the  Tag_name 
is  set  appropriately. 

Processing. 

This  paragraph  contains  a  high-level  description  of  the  process  called  reg_ag. 

get_user_input  (Tsubsystem)  =  TSUBSYSTEM 
get  user  input  (Tboard)  =  TBOARD 

display  fag_names  of  nodes  on  TSUBSYSTEM  and  TBOARD 
get_user_input  (Tag_name)  =  TAG_NAME 
display  nodes  with  TAG_NAME  in  colorl 
display  nodes  with  any  T8p_ag_name  in  color2 
display  other  nodes  in  coiorS 
while  get_user_input  (node_name}  =  NODE_ID 
if  color  (NODE_ID)  =  colorl 

color  (NODE_ID)  =  colors 
color  node  NODE_ID  in  colorl 
if  get_user_input  (done) 

while  nodes  that  are  colorl 

Tag_name  (node_name)  =  TAG_NAME 
if  node_name  (Tsp_ag_name) 

T8p_ag_name  (node_nanie)  =  null 

exit 

endif 

endwhile 

endif 

endwhile. 
conn  check. 


Limitations. 

ADAS  data  base  graphs  must  have  been  created  prior  to  entering  TEA. 

Ambiguity  groupings  are  required  to  have  unique  names  on  any  one  board.  If  boards 
are  divided  among  graphs,  then  reg_ag  will  have  to  be  executed  once  per  grapl.  to 
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fully  itemize  all  regular  ambiguity  groups. 

The  user  may  not  add  any  new  ambiguity  groups  with  reg_ag. 

Nodes  that  are  part  of  a  special  ambiguity  group  cannot  also  belong  to  a  regular  ambi¬ 
guity  group.  Tsp_ag_name  gets  cleared. 

Only  one  ambiguity  group  may  be  edited  or  viewed  with  a  call  to  ag_naine.  If  the 
user  needs  to  edit  or  view  multiple  groups,  multiple  calls  must  be  made. 

Outputs. 

The  Tsp_ag_name  and  Tag_name  attributes  are  updated. 

The  following  is  a  brief  report  that  shows  that  conn_check  is  run  after  reg_ag  is  run 
to  make  sure  that  the  user  has  not  destroyed  the  connectivity  that  needs  to  be  present 
for  appropriate  addition  of  a  BIT  technique.  A  report  will  only  be  generated  if 
conn_check  finds  a  connectivity  error.  Here,  ambiguity  group  “agl”  has  become 
disconnected.  Nodes  assigned  to  “agl”  are  bitl,  FFl,  CTRl,  bits,  and  CTR2. 


***Insert  STANDARD  HEADER  here*** 


AMBIGUITY  GROUP  NAMES 
(ag_naine  conn_check) 

AG  ‘agl’  containing  the  following  nodes  is  not  connected 
bitl 
FFl 
CTRl 
bits 

CTR2 

ag_name  conn_check  completed 


Error  Message /Action. 

Additional  Information. 

See  paragraphs  describing 

a.  data  base  attributes  and  valid  syntaxes  (Paragraph  2.3.2) 

b.  conn_check  (Paragraph  2. 6. 1.1) 

c.  output  report  header  information  (Paragraph  2. 6.2.1) 


2. 6. 1.3.  Special  Ambiguity  Groups  (spcl  ag). 

The  purpose  of  having  special  ambiguity  groupings  is  to  influence  the  BIT  Recommen¬ 
dation,  BIT  Overhead  Summary,  and  BIT  Placement  Recommendation  tools.  The  user 
has  control  over  these  special  groupings  and  can  change  them  using  spcl_ag  to  see 
how  these  groups  affect  the  outputs  of  these  tools. 
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The  user  introduces  special  ambiguity  groups  because  he  has  nodes  that  he  wants  to 
test  as  a  group.  These  can  arise  because  of  computed  test  vectors  or  error  analysis. 
The  designer  may  have  unique  insight  gathered  from  a  previous  design,  or  he  may  be 
more  comfortable  with  predetermined  groupings. 

When  the  BIT  Recommendation  Tool  recommends  groupings,  function  is  not  con¬ 
sidered  very  significantly.  As  an  example  of  a  special  ambiguity  group,  the  user  may 
wish  to  combine  address  decoders  with  input  latches  as  a  standard  practice.  This  is 
done  using  ag_name  spcl_ag  before  running  the  BIT  Recommendation  Tool. 

The  purpose  of  spcl_ag  is  to 

a.  allow  the  user  to  conveniently  view  nodes  in  specific  special  ambiguity  groups 

b.  add  special  ambiguity  groups 

c.  edit  the  Tsp_ag_name  of  any  node  assigned  to  a  special  ambiguity  group. 
Note  that  the  output  of  BIT  Recommendation  is  invalidated  if  the  user  makes 
changes  with  spcl_ag.  The  user  may  assign  nodes  from  special  ambiguity 
groups  to  regular  ambiguity  groups,  thus  further  affecting  the  output  of  BIT 
Overhead  Summary. 

Inputs. 

The  user  inputs  the  board  and  subsystem  names.  If  the  user  wishes  to  add  nodes  to  a 
new  group,  the  user  will  have  to  signal  the  tool  with  the  name  of  the  new  group.  The 
next  menu  shows  all  nodes  on  the  board.  Those  that  are  currently  assigned  to  the  spe¬ 
cial  ambiguity  group  are  shown  in  one  color  (violet),  ones  that  are  assigned  to  any 
other  special  ambiguity  groups  are  shown  in  another  (magenta),  ones  assigned  to  regu¬ 
lar  ambiguity  groups  are  shown  in  a  third  (orange),  and  all  others  are  shown  in  white. 

The  Tsp_ag_name  attribute  of  each  node  assigned  to  an  ambiguity  group  is  updated 
to  reflect  the  special  ambiguity  group  name.  If  a  regular  ambiguity  group  node  is 
switched  to  a  special  ambiguity  group,  the  Tag_name  attribute  is  cleared  and  the 
Tsp_ag_naiTie  is  set  appropriately.  Conn_check  is  run  to  make  sure  that  all  ambi¬ 
guity  groups  are  connected. 

Processing. 

This  paragraph  contains  a  high-level  description  of  the  process  called  spcl_ag. 

get_user_input  (Tsubsystem)  =  TSUBSYSTEM 
get_user_input  (Tboard)  =  TBOARD 

display  Tsp_ag_names  of  nodes  on  TSUBSYSTEM  and  TBOARD 
get_user_input  (Tsp_ag_name)  =  TSP_TAG_NAME 
display  nodes  with  TSP_TAG_NAME  in  colorl 
display  nodes  with  any  Tsp_ag_name  in  color2 
display  other  nodes  in  colors 
while  get_user_input  (node_name)  =  NODE_ID 
if  color  (NODE_ID)  =  colorl 

color  (NODE  ID)  =  colorS 
color  node  NODE_ID  in  colorl 
if  get_user_input  (done) 

while  nodes  that  are  colorl 
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Tsp_ag_name  (node_name)  =  SPTAGNAME 
if  node_name  (Tag_name) 

Tag_name  (node  name)  =  null 

exit 

endif 

endwhile 

endif 

endwhile. 

conn_check. 

Limitations. 

ADAS  data  base  graphs  must  have  been  created  prior  to  entering  the  TEA. 

Ambiguity  groupings  are  required  to  have  unique  names  on  any  one  board.  If  boards 
are  divided  among  graphs,  spcl_ag  will  have  to  be  executed  once  per  graph  to  fully 
itemize  all  special  ambiguity  groups. 

Nodes  that  are  part  of  a  special  ambiguity  group  cannot  also  be  part  of  a  regular  ambi¬ 
guity  group.  Tsp_ag_name  get  cleared. 

Biports  are  ignored. 

TEA  supports  the  concept  of  ADAS  buses,  but  all  buses  are  assumed  to  be  a  single  bit 
in  width. 

Only  one  ambiguity  group  may  be  edited  or  viewed  with  a  call  to  ag_name.  If  the 
user  needs  to  edit  or  view  multiple  groups,  multiple  calls  must  be  made. 

Outputs. 

The  Tsp_ag_name  and  Tag_name  attributes  are  updated. 

Error  Message /Action. 

Additional  Information. 

See  paragraphs  describing 

a.  conn_check  (Paragraph  2.6. 1.1) 


2.6.2.  Report  Generation /Access  (log  file).  Output  from  TEA  is  available  from  the 
“Report  Generation/Access”  routine.  Each  TEA  tool  generates  a  slightly  different 
form  of  output  during  execution.  The  purpose  of  the  report  generator  is  to  collect  all 
significant  data  and  generate  a  useful  output  report.  Dft  is  different  from  the  other 
tools,  as  it  creates  an  intermediate  file  and  the  report  generator  transforms  it  into  a 
“normal”  output  file.  The  log_fiIe  (report  access)  option  of  the  TEA  top-level  menu 
is  used  to  either  view  the  report  or  print  the  report  on  a  local  printer. 
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TEA  reports  are  created  in  files  with  extensions 

a.  rpt 

b.  dwg 

c.  help 

depending  on  the  tool  and  contents.  The  report  access  routine  will  only  be  looking  for 
files  with  these  extensions. 

2.6.2.I.  Report  Generation.  This  is  a  unique  TEA  utility  because  it  cannot  be  accessed 
from  any  menu;  it  is  automatically  called  at  the  end  of  each  tool  run. 

Inputs. 

The  “current  view”  ADAS  data  base,  operating  system  variables,  output  from  a  TEA 
tool,  and  the  TEA  menu  data  bases  are  the  inputs  to  report  generator.  The  “current 
view”  data  base  and  TEA  menu  data  base  provide  intermediate  information  to  the 
report  generator. 

Information  from  the  operating  system  (e.g.,  user’s  name),  needed  for  the  output 
report  header,  is  obtained  directly  from  the  operating  system. 

The  results,  trap  file  contains  all  information  that  identifies  violations  found  by  dft. 
The  format  has  been  defined  such  that  the  TEA  report  generator,  written  in  C,  can 
access  the  results  of  the  dft  Prolog  code.  This  file  is  removed  by  the  report  generator 
after  it  has  been  transformed  into  a  “normal”  output  report. 

Each  dft  guideline  executed  inserts  a  predefined  header  to  identify  to  the  report  gen¬ 
erator  which  guideline  violations  are  to  follow.  This  is  represented  in  the  file  as 
’*gl_02*’.  The  violations  are  then  listed  in  one  of  two  ways 

a.  single  node  violations, 

b.  list  of  node  violations. 

A  single  node  violation  is  represented  in  the  results,  tmp  file  as  a  two  line  entry.  The 
first  line  is  the  standard  guideline  header,  ’*gl_02*’,  and  the  second  line  identifies  the 
specific  node  in  violation  of  the  guideline  along  with  the  specific  type  of  violation,  the 
port,  and  any  other  specific  node  information  required  to  generate  the  output  report. 

A  list  of  violations  is  represented  in  the  same  way  as  single  violations,  however,  multi¬ 
ple  nodes  are  listed  after  the  guideline  header  instead  of  one. 

In  addition,  information  for  the  output  report  is  contained  within  the  results,  tmp  file 
which  is  not  part  of  the  violation.  These  are  lists  of  nodes  which  represent  a  certain 
type  or  function.  The  information  lists  are  represented  by  unique  header,  such  as 
’*gl_02_ff_ctr_srjist*’,  on  a  single  line,  followed  by  the  list  of  nodes.  Each  node  in 
tne  list  is  on  a  separate  line  and  enclosed  in  asterisks  so  that  the  node  is  not 
highlighted,  like  nodes  involved  in  violations. 
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A  sample  results,  tmp  file: 


*DFT_Analyze* 

*gl_02* 

*gl_02* 

U22  rl  port=7  clear 
*gl_02* 

U24  rl  port=7  clear 
*gl_02* 

U25  rl  port=7  clear 
*  g  l_02_ff_c  t  r_sr_list  * 
*U10* 

*U11* 

*U12* 

*U13* 

*U14* 

*U15* 

*U16* 

*U18* 

*U2* 

*U22* 

*U24* 

*U25* 

*U4* 

*U5* 

*U6* 

*V7* 

*U8* 

*U9* 

*done_report_list* 

*gl_02_END* 


Explanation: 

Node  “U22”  has  a  violation  of  guideline  gl_02  at  port  7.  The  inport_id  (or  name)  of 
this  port  is  “clear.”  The  violation  is  “rl”  which  states  that  the  “clear”  inport  of  node 
“U22”  is  not  primary  input  controllable.  Node  “U22”  is  highlighted. 


A  list  of  flipflops,  counters,  and  shift  registers  found  in  the  “current  view.”  Asterics 
indicate  that  the  node  is  NOT  to  be  highlighted. 


Processing. 

The  following  presents  the  high-level  algorithms,  special  control  features,  and  error 
handling  features  of  the  report  generator. 
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AskUserForFileName(Tool_n.extension) 

If(FileName. extension  EXISTS) 

IncrementV  ersionN  uniber(n) 

If(Tool  =  dft) 

Open(results.tmp) 

If  Open(results.tmp)  =  NULL 

Write(results.tmp:  can’t  be  opened) 
Exit 

Open(File.extension) 

GetHeaderlnfo 

Print(Header) 

Case  Buffer 

Tooll/Optionl: 

Call  Print_Tooll_Optionl() 
Tooll  /  Option2: 

Call  Print_Tooll_Option2() 


EndCase 

Close(File.extension) 

End. 

Limitations. 

The  report  generator  is  unaccessible  via  any  TEA  menu.  At  the  completion  of  a  TEA 
tool’s  execution,  the  process  is  started  and  a  report  is  generated  in  the  local  directory. 

An  appropriate  filename  extension  (.rpt,  .dwg,  .help)  will  be  added  to  user-specified 
filenames,  if  they  are  not  specified. 

Outputs. 

At  the  completion  of  report  generator,  a  file  is  generated  in  the  current  directory  for 
use  by  the  report  access  routine.  The  filename  is  (by  default)  toolname_n.rpt,  where  n 
is  the  next  higher  integer  of  any  other  report  file  from  the  same  tool.  Wiring  diagrams 
will  be  output  by  placebit  and  compare  (see  Paragraphs  2.7.4  and  2.7.5).  These  files 
will  have  the  filename  format  toolname_n.dwg.  dft  explain  (see  Paragraph  2.7.1)  will 
output  files  of  the  format  rule_name.help.  Examples  of  a  output  reports  will  be  illus¬ 
trated  in  the  discussions  of  the  TEA  utilities  and  tools  in  Paragraphs  2.6  and  2.7. 

If  colors  are  changed  on  the  “current  view”  as  the  result  of  tool  output,  original  node 
and  arc  coloring  can  be  restored  by  using  the  window  utility,  selecting  the  center  of 
the  screen  and  a  scale  factor  of  0. 

If  the  user  does  not  want  to  receive  one  or  more  of  the  output  reports,  he  should  insert 
nl:  in  response  to  the  prompt. 

All  output  reports  will  have  a  standard  header  as  shown  in  Figure  2-5.  The  standard 
header  shows  the  date  and  time  of  creation,  the  user,  the  graph  name,  the  data  base 
filename,  and  the  output  report  name. 
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Test  Engineer’s  Assistant  (TEA)  Output  Report 

ADAS/TEA  Version:  PROTO.TYPE 
Research  Triangle  Institute 
P.O.  Box  12194 

Research  Triangle  Park,  NC  27709 
Date/Time:  Thu  Oct  15  09:04:35  1987 
User;  OTOOLE 

Graph: 

Current  View  Graph:  Avionic_System_Hardware 

Current  View  Filename:  system.hwg 

Output  Report  Filename  =  system.rpt 


Tool  name 
(options  list) 

Figure  2-5.  Example  of  Generated  Report  Header 

Error  Message /Action. 


Message 

Action 

The  results.tmp  file  does  not  exist 

Make  sure  that  dfi  results  are 
available 

The  output  file  cannot  be  opened 

Check  read/write  privileges 

Report  Generator  is  not  available 
for  <  undefined  function  > 

Check  input 

Additional  Information. 


2.6.2.2.  Report  Access  (log  Tile). 

Inputs. 

The  user  must  select  log_file  from  the  TEA  top-level  menu.  From  the  submenu,  the 
user  selects  either  view  or  print.  The  user  must  then  select  the  directory  and  file  to 
be  displayed. 

Processing. 

If  the  tool  is  in  view  mode,  log_fiIe  will  use  the  type/page  VMS  command.  If  the 
tool  is  in  print  mode,  log_file  will  use  the  VMS  print  command  with  no  options. 
The  default  printer  is  used.  All  files  ending  in  .rpt,  .help,  and  .dwg  in  the  chosen 
directory  will  be  listed. 
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Limitations. 


Outputs. 

Data  is  either  spooled  to  the  terminal  or  the  default  printer. 
Error  Message /Action. 

Additional  Information. 

See  paragraph  describing 

a.  report  generation  (Paragraph  2.6.2.1) 


2.6.3.  On-line  User  Support  System  (help  /  %help).  The  On-Line  User  Support  System 
is  a  readily-available  reference  for  the  user  of  the  Test  Engineer’s  Assistant.  The 
material  which  can  be  referenced  by  the  user  has  information  about  each  of  the  tools 
and  utilities,  especially  the  User  Interface.  The  on-line  material  references  hardcopy 
documentation  when  available.  Special  attention  is  paid  to  each  of  the  design  for  tes¬ 
tability  guidelines  (e.g.,  statement,  how  they  add  to  testability,  alternative  constructs, 
and  attribute  syntax). 

Most  menus  associated  with  the  User_Interface  will  have  a  %help  choice  available; 
this  allows  the  user  to  indicate  that  he  wishes  further  information.  Depending  on  the 
menu  from  which  %help  is  chosen,  the  user  will  be  directed  to  the  material  most  per¬ 
tinent  to  the  tool  and  to  the  submenu  he  had  been  investigating.  In  this  way,  the 
material  that  is  most  useful  or  timely  will  be  provided  first.  TEA’s  top-level  menu  has 
a  help  option  instead  of  %help  like  all  other  menus. 

The  storage  of  the  on-line  documentation  is  hierarchical;  therefore,  if  the  information 
provided  initially  to  the  user  is  not  what  is  needed,  the  user  can  either  step  further 
into  the  hierarchy  (more  specific  information)  or  back  out  (less  specific)  and  take 
another  path.  %help  is  a  short-cut  into  the  on-line  documentation.  When  %help  is 
chosen  as  the  menu  option,  the  user  is  returned  to  the  calling  menu  when  the  on-line 
documentation  is  exited.  The  explain  option  of  the  Design  for  Testability  Guideline 
Checker  allows  a  shortcut  to  the  information  concerning  each  of  the  guidelines  imple¬ 
mented. 

Inputs. 

The  user  must  chose  %help  from  a  menu,  any  of  the  Design  for  Testability  Guideline 
Checker  (dft)  explain  options,  or  placebit  <  technique >  no  to  access  the  library. 

Process  Control. 

Three  possible  process  control  scenarios  can  occur: 

a.  when  a  user  selects  %help,  he  has  unlimited  access  to  the  on-line  user  docu¬ 
mentation  until  he  exits,  then  the  process  control  is  returned  to  the  calling 
menu 
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b.  when' a  user  selects  dft  explain,  he  has  unlimited  access  to  the  on-line  user 
documentation  until  he  exits,  then  process  control  is  returned  to  the  TEA 
top-level  menu 

c.  when  a  user  selects  placebit  < technique >  no,  he  will  get  general  informa¬ 
tion  about  the  chosen  technique  dumped  to  a  file  called  placebit_n.help  by 
default 

Processing. 

Refer  to  Chapter  8  of  the  VAX/VMS  Utility  Routines  Reference  Manual.  April  1986. 
Limitations. 

ADAS  data  base  graphs  must  already  have  been  created  before  TEA  is  entered. 
Outputs. 

No  files  are  created  by  the  On-line  User  Support  System.  If  the  user  indicates  that  he 
wants  to  save  the  output  of  an  dft  explain  session,  the  User_Interface  invokes  the 
Report  Generator.  The  Report  Generator  is  automatically  invoked  if  placebit 
< technique >  no  is  selected. 

Error  Message /Action. 

.\dditional  Information. 

See  paragraph  describing 

a.  dft  explain  output  report  example  (Paragraph  2.7.1) 

2.6.4.  Save  (save). 

The  save  function  provides  a  method  for  the  user  to  write  changes  made  to  the 
“current  view”  data  base  files.  The  TEA  save  function  differs  from  the  .AD-A.S  save 
function  in  that  the  user  is  allowed  to  save  a  copy  of  the  current  graph  and  associated 
subgraphs  under  a  new  filename.  TEA  will  also  allow  overwriting  of  the  existing  file, 
just  as  ADAS  does.  The  new  feature  allows  the  original  graph  data  base  to  be 
retained,  if  desired.  This  option  is  valuable  in  cases  where  incremental  changes  must 
be  assessed  for  one  reason  or  another.  An  example  would  be  a  cost  assessment  trade-off 
study  where  the  total  computed  cost  is  not  always  the  linear  sum  of  the  individual 
changes.  By  retaining  previous  versions  of  the  hardware  graph,  multiple  combinations 
may  be  analyzed. 
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Inputs.  The  save  unit  has  several  inputs  depending  on  the  menu  options  selected  by 
the  user: 

a.  the  “current  graph”  filename 

b.  the  filename  for  the  copied  graph  (if  required) 

c.  the  filename  of  all  subgraphs  (if  required) 

d.  the  “.hwg”  filenames  in  the  directory  to  which  a  copy  of  the  “current  graph” 
is  to  be  made  (if  required) 

e.  user  commands  to  traverse  through  the  menu  hierarchy 

The  “current  graph”  filename  represents  the  original  graph  before  any  changes  were 
made  in  the  current  TEA  session.  When  a  graph  structure  is  copied  to  another  file. 
tea’s  user  interface  checks  the  user’s  VMS  directory  for  existing  hardware  graph  files 
of  the  same  name.  If  a  file  already  exists,  the  user  is  prompted  to  specify  a  new 
filename.  When  prompted,  the  user  may  also  specify  a  filename,  located  in  another 
directory,  by  specifying  the  full  VJ^IS  path. 

Processing.  The  save  command  has  two  subfunctions: 

a.  the  new_copy  command  for  saving  a  copy  of  the  current  graph,  subgraphs, 
and  template  files  to  an  external  file/tree  structure  without  altering  the  origi¬ 
nal  data  base  files 

b.  the  overwrite  command  to  save  the  “current  view”  graph  in  the  current  data 
base  files  without  making  a  copy  of  the  structure 

Graphs  which  are  saved  using  the  new_copy  command  are  copies  of  the  “current 
view”  graph  with  all  the  associated  subgraphs  and  template  files.  The  user  is 
prompted  for  the  filename  where  the  copied  graph  will  reside.  All  subgraph  name 
attributes  are  automatically  modified  to  accommodate  the  new  filenames. 

To  protect  the  user  against  the  quit  save  option,  the  user  is  prompted  to  indicate 
whether  the  “current  view”  graph  should  be  overwritten  with  the  modified  “current 
view”  graph. 

Limitations. 

.ADAS  data  base  graphs  must  already  have  been  created  before  TEA  is  entered. 
Outputs. 

Either  new  files  or  new  versions  of  old  files  are  created  in  the  appropriate  directory. 
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2.7.  The  TEA  Tools.  The  set  of  tools  developed  as  part  of  TEA  includes  five  processes 
which  will  be  described  here.  Fissure  2-6  is  a  diagram  depicting  these  tools  and  the 
information  obtained  from  each.  The  following  paragraphs  will  describe  the  inputs, 
outputs,  limitations,  and  processing  needed  for  each  tool. 

The  TEA  system  accepts- an  .\DAS  schematic  of  the  system,  which  has  been  function¬ 
ally  verified  using  VTIDL,  as  its  input.  .After  BIT  has  been  added  to  the  system,  the 
TEA  methodology  supports  resimulation  of  the  system  in  VTIDL  with  the  added  BIT 
features  and  test  modes  by  providing  VHDL  descriptions  of  the  BIT  modules  and  by 
instructing  in  the  use  of  the  modules  under  normal  and  test  modes. 

The  Design  for  Testability  Guideline  Checker,  or  dft.  uses  a  data  base  of  commonly 
accepted  design  for  testability  guidelines  to  identify  hard-to-test  and  untestable  struc¬ 
tures  in  a  digital  board  design.  The  design  topology  and  functions  are  compared  to  the 
guidelines  (rules)  and  if  any  violations  are  found,  a  message  is  issued  to  the  user.  On¬ 
line  documentation  and  support  facilities  aid  the  designer  in  removing  or  replacing  the 
predefined  untestable  structures  with  more  easily  testable  substitutes  w-hich  guide  the 
user  to  a  testable  design.  Explanation  of  why  a  particular  structure  is  untestable  is 
also  provided  upon  request. 

The  guidelines,  or  rules,  are  roughly  divided  into  two  groups:  those  that  aid  test  pat¬ 
tern  generation  (e.g.,  make  any  buried  control  line  primary  input  controllable)  and 
those  that  aid  test  pattern  application  and  fault  isolation  (e.g.,  break  up  long  counter 
chains  with  logic  that  allows  direct  external  control),  .\pproximately  25  predefined 
guidelines  are  implemented  in  the  current  version  of  the  tool,  .\dditionally,  a  utility  is 
provided  so  that  dft  can  be  field- upgradable  with  user-installed  guidelines. 

When  a  testability  inhibiting  factor  (e.g.,  uncontrollable  feedback)  is  found  in  the 
design,  the  user’s  “current  view’’  is  updated  to  show  the  violation  in  contrasting  colors, 
and  a  report  file  is  written  showing  the  modules  forming  the  pattern  in  violation  and 
alternatives  to  that  structure. 

Dft  uses  a  directed  graph  view  of  the  system  as  its  input.  The  tool  then  uses  graph 
traversal  and  pattern  matching  procedures  to  analyze  the  graph  for  design  for  testabil¬ 
ity  guideline  violations.  The  graph  traversal  techniques  are  used  so  that  many  possible 
occurrence  variations  can  be  matched  with  the  general  guidelines. 

In  addition  to  the  analyze  function  described  above,  dft  provides  both  an  identify  and 
an  explain  function.  The  identify  function  allows  the  user  to  select  a  particular 
schematic  component  (e.g.,  all  test  points),  and  that  component  is  highlighted  on  the 
“current  view.”  The  explain  function  allows  the  user  to  see  all  the  on-line  information 
available  about  a  particular  guideline,  including  the  purpose  of  the  guideline  (e.g., 
avoid  one-shots  as  delay  elements  because  of  their  tendency  to  drift  and  provide 
unreliable  timing  pulses)  and  alternative  constructions  (e.g.,  use  counters  or  timers 
instead  of  one-shots  for  delay  elements). 
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Figure  2-6.  Block  Diagram  Description  of  the  TEA  System 
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Once  untestable  features  have  been  removed  from  a  design.  BIT  can  effectively  be 
added.  Three  tools  provide  the  TEA  BIT  support  functions.  They  can  be  invoked  on 
each  board  as  attributes  of  the  system  change  so  that  the  user  can  view  the  effect  of 
the  attributes  on  the  results.  For  instance,  the  user  may  define  special  ambiguity 
groups,  or  groups  of  chips  to  be  tested  together,  and  the  tool  will  assign  the  remaining 
groups  to  maintain  these  special  groups.  The  tools  communicate  with  each  other  by 
updating  the  internal  schematic  data  structure.  Each  tool  provides  the  user  with 
reports  of  its  recommendations  and/or  findings. 

BIT  Recommendation,  or  brt,  uses  linear  programming  techniques  to  assign  chips  to 
AGs,  such  that  the  AG  maximum  size  requirement  is  met  and  the  input/output 
to/from  the  AG  is  minimized  so  that  the  hardware  needed  to  monitor  the  groups  is 
also  minimized.  Secondary  constraints  on  AG  choices  can  include  such  testability  fac¬ 
tors  as  reliability,  cost  to  replace,  and  difficulty  in  obtaining  test  vectors.  After  the 
AG  partitioning  is  accomplished,  the  tool  recommends  a  BIT  technique  for  each  AG: 
however,  if  sufficient  information  about  the  board  is  not  available,  the  user  must 
choose  a  upported  BIT  technique.  TEA  supports  both  on-line  and  off-line  BIT  tech¬ 
niques.  The  off-line  techniques  include  deterministic,  pseudorandom,  and  combina¬ 
tions  of  deterministic  and  pseudorandom  test  pattern  techniques. 

Once  chips  have  been  assigned  to  AGs,  BIT  Overhead  Summary,  or  bit_cost.  calcu¬ 
lates  the  hardware  overhead  needed  to  adequately  monitor  the  groups  given  the  chosen 
BIT  technique.  This  tool  has  knowledge  of  a  data  base  of  provided  BIT  modules  and 
knows  about  how  to  assign  observation  and  control  points  to  the  modules  to  obtain  the 
fault  isolation  desired  without  over  burdening  the  circuit. 

BIT  Placement  Recommendation,  or  placebit,  uses  the  chosen  BIT  technique  and  the 
ambiguity  group  information  derived  by  BIT  Recommendation  to  update  the 
schematic  to  show  the  addition  of  the  BIT  support  modules  and  required  test  points. 
The  exact  overhead  required  for  this  particular  set  of  graphs  is  known  after  this  tool 
has  been  run. 

At  any  point  in  the  TEA  methodology  the  user  can  choose  to  “freeze"’  versions  of  the 
graph  hierarchy  to  use  as  “baselines”  or  checkpoints  on  the  design.  In  addition  to 
being  an  aid  to  design  documentation,  System  Summary,  or  compare  measures  any 
change  in  the  graphs  that  possibly  contributes  to  the  testability  of  the  design.  Dft 
and  brt  give  recommendations  that  may  significantly  affect  these  factors. 

It  is  recommended  that  the  user  make  frequent  use  of  the  TEA  utility  save  so  that 
intermediate  results  from  the  TEA  tools  are  not  inadvertently  lost. 

2.7.1.  Design  for  Testability  Guideline  Checker  (dft).  One  of  the  approaches  used  to 
reduce  testing  costs  (e.g.,  length  of  test  vector  sequence,  number  of  test  points)  is  to 
recognize  testing  difficulties  when  designing  the  system,  subsystem,  board,  or  chip  and 
incorporate  certain  features  in  the  design.  In  other  words,  we  must  include  testability 
requirements  as  design  parameters  at  all  levels  of  the  design  hierarchy.  This  procedure 
is  known  as  design  for  testability  (DFT),  where  testability  is  defined  as  a  design 
characteristic  which  allows  the  unit’s  status  (operable,  inoperable,  or  degraded)  and 
the  fault  locations  within  the  unit  to  be  confidently  determined  in  a  timely  fashion. 
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The  incorporation  of  design  for  testability  methods  in  electronics  first  became  practical 
with  the  onset  of  LSI  logic  in  the  1970’s.  Though  the  military  has  devoted  much  effort 
to  DFT,  no  integrated  procedure  for  incorporating  testability  requirements  existed  in 
military  programs  until  recently.  This  has  been  remedied  by  the  issuance  of  MIL-STD- 
2165  in  1985  by  the  Navy  Test  and  Monitoring  Systems  and  the  Joint  Logistics  Com¬ 
mander  Panel  on  Automatic  Testing.  This  standard,  along  with  other  guidelines  and 
standards,  will  define  and  coordinate  the  inclusion  of  testability  requirements  in  elec¬ 
tronic  systems  of  the  future. 

In  dealing  with  the  testability  of  a  design,  two  key  underlying  concepts,  controllability 
and  observability,  are  often  used.  Controllability  is  defined  as  a  relative  measure  of 
how  easily  a  node  or  point  can  be  forced  to  a  specific  logic  value  by  setting  the  inputs. 
Likewise,  observability  is  a  measure  of  how  easily  the  logical  value  of  a  node  can  be 
propagated  through  the  unit  to  a  primary  output  where  it  can  be  noted.  Many  of  the 
common  DFT  techniques  are  used  to  enhance  the  controllability  and  observability  of 
certain  parts  of  a  design  in  order  to  ease  the  testing  problem. 

The  purpose  of  the  DFT  Guideline  Checker  is 

a.  to  check  features  of  a  board  level  design  captured  in  ADAS  hardware  graphs 
for  untestable  and  hard-to-test  constructs, 

b.  to  identify  connectivity  and  attribute  information  needed  to  assess  the  appli¬ 
cability  of  the  DFT  guidelines,  and 

c.  to  generate  a  report  for  guiding  the  designer  toward  design  testability  improve¬ 
ment  by  recommending  different  constructs  and/or  different  modules. 

The  guidelines  on  which  the  Checker  functions  operate  are  divided  into  two  groups: 
those  that  aid  test  pattern  generation  and  those  that  aid  test  pattern  application.  If 
test  patterns  can  be  written  in  less  time,  the  cost  of  creating  and  maintaining  test  pro¬ 
gram  sets  can  be  reduced.  If  the  time  to  apply  test  patterns  to  a  system  can  be 
reduced,  then  the  time  to  detect  and  isolate  a  faulty  component  is  shortened,  thus  aid¬ 
ing  the  maintenance  function. 

Inputs. 

Before  a  dft  action  can  be  initiated,  an  ADAS  hardware  graph  data  base  must  be 
created  using  the  ADAS  graph  editor,  EDIGRAF.  The  data  base  must  be  initialized  to 
contain  attribute  values  required  for  the  user-selected  actions  (see  Paragraph  2.3.2). 
This  can  be  accomplished  by  using  node  templates  with  the  attributes  preset  or  by 
explicitly  setting  the  values. 

The  internal  representation  of  the  ADAS  hardware  graph  data  base  serves  three  pur¬ 
poses.  First,  a  number  of  attributes  pertaining  to  a  procedure  are  retrieved  from  this 
internal  data  base  for  evaluation  based  on  user-selected  options.  Second,  the  data  base 
is  used  to  allow  the  tool  to  graphically  indicate  its  outputs.  Third,  the  data  base  is 
used  as  a  reference  for  indicating  its  outputs  for  the  generation  of  the  output  report. 

Processing. 

Dft  analyze  and  dft  identify  loops  construct  two  local  files,  graph.pl  is  the  Prolog 
version  of  the  ADAS  data  base,  control.pl  is  the  Prolog  command  file.  Since  dft  is  a 
function  which  operates  on  a  hierarchical  ADAS  hardware  graph  data  base,  a  local 
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data  bai>e  1^  constructed  and  modified  by  actions  taken  while  in  a  TEA  session.  The 
format  of  this  local  data  base  is  identical  to  that  described  in  Appendix  D. 

If  graph.pl  has  been  compiled  since  TEA  was  executed  and  the  data  base  has  not  been 
changed,  graph.pl  will  not  be  recompiled. 

The  following  paragraph  shows  a  very  high-level  description  of  the  algorithm  used  for 

dft. 


Get  user_iiiput(action) 

If  (explain) 

Get  user_input(guiderine) 

Output  report 
Exit. 

If  (analyze) 

Get  user_input(TSUBSYSTEMs) 

Get  user_input(TBOARDs) 

Get  user_input(guidelines) 

For  each  guideline,  TSUBSYSTEM,  TBOARD 
Evaluate; 

If  (identify) 

Get  user_input(TSUBSYSTEM) 

Get  user_input(TBOARD) 

Get  user_input(structure) 

For  structure,  TSUBSYSTEM,  TBOARD 
Identify; 

Output  report 
Exit. 

Limitations. 

ADAS  data  base  graphs  must  already  have  been  created  before  TEA  is  entered. 

For  proper  execution  of  the  dft  procedures,  the  required  attributes  must  have  a  legal 
syntax.  For  each  attribute  there  is  a  library  of  valid  syntaxes  or  spellings  (see  Para¬ 
graph  2.3.2).  The  user  can  view  the  valid  syntax  for  each  attribute  using  the  explain 
tool.  An  invalid  syntax  for  an  attribute  can  cause  the  tool  not  to  execute  or  give 
invalid  results,  depending  on  the  attribute. 

TEA  supports  the  concept  of  ADAS  buses,  but  all  buses  are  assumed  to  be  a  single  bit 
in  width. 

Because  node_name  is  not  a  normal  node  attribute,  dft  identify  attribute 
node_name  gives  an  error  message:  “Can’t  find  attribute  ‘node_naiae’.”  rather  than 
do  what  is  expected. 

Only  one  dft  analyze  can  be  running  in  any  one  directory  at  a  time  since  the  graph 
and  control  Prolog  files  are  always  called  graph.pl  and  control.pl  and  the  results  are 
always  placed  in  results,  tmp. 

Outputs. 

Dft  has  two  outputs,  depending  on  the  actions  taken  by  the  user 

a.  the  current  hierarchical  ADAS  hardware  graph  modified  to  graphically  indicate 
the  results  of  an  action 


2-37 


1.  nodes  not  involved  will  be  colored  dark  gray 

2.  nodes  involved,  but  not  in  violation  will  be  colored  light  gray 

3.  violations  will  be  shown  in  non-gray  tones  (cycling  through  the  following 
color  list:  red,  green,  blue,  cyan,  yellow,  magenta,  dk_red,  dk_green, 
dk_blue,  violet,  dk_yellow,  orange) 

b.  a  report  file  which  contains  the  results  of  an  action 

Following  are  four  example  output  files.  The  first  demonstrates  the  output  from  dft 
analyze  on  multiple  boards  with  multiple  guidelines  chosen.  The  second  shows  the 
output  of  dft  identify  when  the  user  was  looking  for  the  structure  “fanout  >  5”. 
The  third,  very  similar  to  the  second,  shows  the  output  of  dft  identify  when  the  user 
was  looking  for  the  structure  “test  point”.  The  final  example  shows  the  output  of  dft 
explain;  the  user  has  chosen  the  guideline  g2_03’s  description.  The  header  informa¬ 
tion  has  been  removed. 
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***Insert  STANDARD  HEADER  here*** 


DESIGN  FOR  TESTABILITY  GUIDELINE  CHECKER 
(dft  analyze) 

Where: 

Subsystem- 

one 


Board- 

gl5el 

gl5e2 

glSextra 

glSnS 

gl5n9 

Guidelines  Selected- 
gl_10 

gl_ll 

gl_15 


G1  10 


No  elements  were  observed  to  hold  the  properties 
for  this  guideline. 

High  Fanout  (node:port:fanout_number): 

No  elements  were  observed  to  hold  the  properties 
for  this  guideline. 


Gl_ll 

Gl_ll_REC_l  -  To  aid  test  pattern  generation,  all 
unused  inputs  should  be  terminated. 

During  implementation,  port  ’inport=0’  of  node 
‘singlel’  should  be  terminated. 

Gl_ll_REC_l  -  To  aid  test  pattern  generation,  all 
unused  inputs  should  be  terminated. 

During  implementation,  port  ’inport=0’  of  node 
‘extral’  should  be  terminated. 

Gl_ll_REC_l  -  To  aid  test  pattern  generation,  all 
unused  inputs  should  be  terminated. 

During  implementation,  port  ’inport=r  of  node 
‘extral’  should  be  terminated. 

Tristate  Devices: 

No  elements  were  observed  to  hold  the  properties 
for  this  guideline. 


G1  15 
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Gl_15_REC  -  To  aid  test  pattern  generation, 
uncontrollable  feedback  should  be  avoided.  Listed 
below  are  nodes  contained  in  uncontrollable  feedback. 

combnodela 

combnodelb 

combnodelc 

Gl_15_REC  -  To  aid  test  pattern  generation, 
uncontrollable  feedback  should  be  avoided.  Listed 
below  are  nodes  contained  in  uncontrollable  feedback. 

node2a 

node2b 

node2c 

There  were  5  violations  found. 

Note  to  user; 

If  untestable  structures  exist  in 
your  design,  you  should  remove 
or  replace  them  before  continuing 
with  the  addition  of  built-in  test. 

Adding  BIT  to  untestable  circuits 
does  not  necessarily  increase  testability. 

Reminder: 

Design  for  testability  implemented  at  the  board  level 
needs  to  be  supported  at  the  subsystem  and  system 
levels.  Add  appropriate  test  communications 
and  control. 

***«*««  «*«******«*«««*««***««***«*))[«*  ««***4,*#«**«««* 

dft  analyze  completed 


The  user  is  directed  to  Paragraph  3.2  where  each  of  the  design  for  testability  guide¬ 
lines  are  discussed.  gl_10  finds  high  fanout  nodes;  none  were  encountered  on  the 
boards  analyzed.  gl_ll  finds  unused  inputs  and  unterminated  tristate  outputs;  multi¬ 
ple  unused  inputs  are  noted,  however  no  unterminated  tristate  outputs  were  found. 
gl_15  finds  uncontrollable  feedback  loop  patterns;  two  were  noted  and  the  nodes  form¬ 
ing  those  loops  are  listed.  Only  the  largest  loops  are  reported  to  the  user.  Loops 
within  larger  loops  are  not  found. 
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***Insert  STANDARD  HEADER  here*** 


DESIGN  FOR  TESTABILITY  GUIDELINE  CHECKER 
(dft  identify) 

What;  Fanout  >  5 

Where: 

Subsystem- 

one 


Board- 

bl 

bX 

Nodes  having  fanout  greater  than  5 
Tag_name2 
P07 

Tag_name3 

n4a 

nodes 

dft  identify  completed 


dft  identify  has  identified  five  nodes  that  have  an  outport  connected  to  5  or  more 
other  nodes.  These  nodes  are  listed. 


♦♦♦Insert  STANDARD  HEADER  here*** 


DESIGN  FOR  TESTABILITY  GUIDELINE  CHECKER 
(dft  identify) 

What:  test_point 

Where: 

Subsystem- 

one 


Board- 

b3 

b8 

bX 

The  following  arcs  were  found 
tpo8a/0_in 
tpo8b/0_in 
tpo8c/0_in 
tpo8d/0_in 
tpo8e/0_in 

dft  identify  completed 
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dft  identify  has  identified  five  arcs  that  have  been  assigned  as  test  points.  These 
nodes  and  their  associated  test  point  inport  are  listed. 


***Insert  STANDARD  HEADER  here*** 


DESIGN  FOR  TESTABILITY  GUIDELINE  CHECKER 
(dft  explain) 

TOOLS 

DFT_ChecIcer 

Rules 

G2_03 

G2_03  Rule:  Break  up  long  counter  chains  greater  than  8  bits 
with  logic  that  contains  primary  inputs  or  primary  input 
controllable  lines. 

Why? 

Because  this  results  in  reduction  of  the  number  of  test 
patterns  required  to  fully  test  the  counter. 

NOTE:  Follow  this  guideline  when  you  use  more  than  one 
counter  chip  to  form  long  counters.  Do  not  replace  a  single 
chip  (long)  counter  with  several  short  counter  chips. 

How? 

Add  shorter  bit  counters  to  the  circuit  and  provide 
appropriate  control. 

Syntax 

inport_id:  clock,  elk 
outport_id:  co,  carry _out 
Tarc_type:  clock,  elk,  data,  cntrl,  Ctrl,  control 
Tdft_io:  primary_input,  pi,  primary_output,  po, 
test_pt_output,  test_point,  tp,  tpo 
Tlogic_type:  combinational,  comb_logic,  comb 
Tnode_type:  counter,  ctr 

dft  explain  completed 


dft  explain  has  dumped  the  information  stored  in  the  On-line  User  Support  System 
about  guideline  g2_03  (Break  up  long  counter  chains.)  to  an  output  report.  Sections  of 
this  information  include  a  statement  of  the  rule,  an  explanation  of  why  this  rule  has 
been  included  in  the  data  base,  an  alternative  structure  to  the  one  found  in  the  graph, 
and  the  valid  syntax  of  the  attributes  Involved  in  the  guideline. 

Error  Message/Action. 

Additional  Information. 

See  paragraphs  describing 

a.  data  base  attributes  and  valid  syntaxes  (Paragraph  2.3.2) 
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b.  results.tmp  file  (Paragraph  2. 6.2.1) 

c.  output  report  header  (Figure  2-5) 

d.  dft  guidelines  (Paragraph  3.2) 

e.  how  to  add  user-defined  guidelines  to  the  data  base  (Paragraph  3.2.4) 


2.7.2.  BIT  Recommendation  Tool  (brt).  The  BIT  Recommendation  Tool  (brt)  process 
advises  the  user  on  the  “best”  general  choice  of  board  level  BIT  technique  given  a 
description  of  a  digital  hardware  board. 

A  testing  methodology  and  grouping  recommendation  are  assigned  to  each  valid  node 
on  a  particular  board  and  subsystem,  the  nodes  are  divided  into  ambiguity  groups 
(AGs)  to  meet  a  maximum  size  (number  of  nodes)  requirement,  and  then  a  testing 
methodology  recommendation  is  assigned  to  each  AG.  Valid  nodes  are  those  nodes  not 
assigned  to  a  special  AG  (see  Paragraph  2.6.3)  by  the  user  or  have  other  predetermined 
unique  testing  requirements  (see  section  below  entitled  “REMOVE  NON-VALID 
NODES”). 

The  recommendation  for  each  node  takes  on  a  value  which  refers  to  the  “best”  method 
of  generating  input,  or  test,  vectors  for  the  node  and  will  take  on  the  value  of  deter¬ 
ministic,  pseudorandom,  don’t  know  (e.g.,  special  case),  or  don’t  care  (i.e.,  can  take  on 
either  deterministic  or  pseudorandom).  The  node  attribute  Ttest  holds  this  value. 
Additionally,  the  node  attribute  Tgroup  takes  on  a  value  of  either  isolate  (i.e.,  test 
alone  or  in  a  specified  group)  or  by  default,  normal  connect  (i.e.,  group  in  a  normal 
AG).  This  attribute  can  also  take  on  the  “eliminate”  value,  which  means  to  not  con¬ 
sider  the  node  any  further  (non-valid  nodes  have  this  value). 

No  specific  BIT  technique  will  be  recommended,  rather  a  class  of  techniques  will  be 
recommended.  Only  off-line,  or  nonconcurrent  testing  techniques  will  be  recom¬ 
mended  by  brt;  however,  TEA  offers  two  concurrent  techniques.  No  attempt  will  be 
made  here  to  summarize  any  information  specific  to  the  techniques  (Paragraph  3.4.2) 
or  to  the  modules  (Paragraph  3.4.3)  supplied  with  TEA  to  support  the  techniques. 

Inputs. 

The  user  specifies  the  board,  subsystem,  and  maximum  ambiguity  group  size.  For 
accurate  results,  the  attributes  listed  in  Paragraph  2.3.2  must  be  completed. 

Processing. 

The  following  paragraph  presents  the  high-level  algorithms,  special  control  features, 
and  error  handling  features  of  brt.  More  description  is  given  for  brt  than  the  other 
tools,  because  brt  uses  many  levels  of  rules  for  deciding  ambiguity  group  partitioning 
which  may  cause  confusion  to  the  user. 
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SIX  MAJOR  MODULES: 

remove  non-valid  nodes  from  consideration 
connectivity  map  procedures 
ambiguity  group  generator 
branch  and  bound 
simplex  method 

assign  test  method  to  ambiguity  groups 
REMOVE  NON-VALID  NODES 

The  objective  of  this  procedure  is  to  assign  a  testing  recommendation  (e.g.,  pseudoran¬ 
dom,  or  deterministic  testing)  to  each  node.  This  is  accomplished  by  appropriately 
completing  the  Ttest  node  attribute  of  the  ADAS  data  base.  The  valid  assignments 
are  shown  in  the  following  list.  Besides  the  testing  recommendation,  the  tool  will 
recommend  to  eliminate  or  isolate  to  ambiguity  groups  nodes  with  special  attributes 
(e.g.,  BIT  modules,  maintenance  nodes,  scannable  chips,  etc.),  using  the  Tgroup  node 
attribute  of  the  ADAS  data  base.  The  tool  assigns  a  testability  recommendation  and  a 
grouping  recommendation  to  each  node. 

In  terms  of  testability  (attribute  Ttest): 

DT:  deterministic  testing 

PS:  pseudorandom  testing  (for  data  lines) 

DC:  don’t  care  situations  (circuit  can  be  tested  efficiently  with  either  PS  or  DT 
patterns) 

DK:  don’t  know  situations  (not  enough  information) 

In  terms  of  grouping  a  node  to  an  ambiguity  group  (attribute  Tgroup): 

IS_ag:  isolate  the  node  in  the  “ag”  ambiguity  group 
NC:  the  node  will  be  grouped  in  an  AG  (default) 

For  both  (Ttest  and  Tgroup): 

EL:  eliminate  the  node  (no  further  testing  considerations)  The  node  will  not  be 
assigned  to  an  ambiguity  group. 

This  routine  starts  with  a  list  of  all  nodes  on  a  particular  board  and  subsystem  and 
then  finds  all  the  special  testing  situations  itemized  in  the  following  rules  and  elim¬ 
inates  nodes  from  the  list,  leaving  only  “valid”  nodes. 

The  following  tests  (a-u)  will  be  examined  in  order,  until  there  is  a  recommendation 
related  to  the  testability  and  a  recommendation  related  to  the  AG  partitioning  for 
each  node.  Once  one  of  the  recommendations  is  found,  it  will  not  be  changed  and  the 
checking  will  continue  until  a  recommendation  is  found  for  the  other  attribute.  New 
suggestions  for  the  recommendation  attributes  will  not  be  considered. 

a.  Clear  Ttest,  Tgroup,  and  Tag_test.  This  implies  that  information  from  pre¬ 
vious  runs  will  be  lost. 

b.  If  the  node  is  self-testable  (see  Tselftest),  mark  the  node  as  Ttest  =  EL, 
Tgroup  =  EL. 


2-44 


c.  If  node  is  analog  (Tdevice_type  =  analog)  or  a  mixture  of  analog  and  digital 
(Tdevice_type  =  mix)  mark  the  node  as  Ttest  =  EL,  Tgroup  =  EL. 

d.  If  the  node  belongs  to  a  ‘‘special”  ambiguity  group  (identified  by  the  user  in 
Tsp_ag_name),  then  mark  the  node  as  Tgroup  =  IS_spec  (where  spec  = 
Tsp_ag_name). 

e.  Mark  maintenance  nodes  as  Ttest  =  EL,  Tgroup  =  EL.  Maintenance 
nodes  can  be  identified  by  Tbit  =  mn,  m_n,  maintenance. 

f.  If  a  node  is  a  JTAG/ETM  support  module  (see  Tscan),  mark  it  as  Tgroup  = 
EL  and  issue  message  about  connecting  it  appropriately.  Tscan  must  be 
marked  “JTAG_SUP”,  ‘‘VHSIC_SUP”,  or  “ETM_SUP”. 

g.  If  a  node  is  a  BIT  support  module  except  scan-set  (i.e.,  Tbit  =  BIT_PS  or 
BIT_DT)  mark  it  as  Tgroup  =  EL  and  issue  message  about  connecting  it 
appropriately. 

h.  Check  if  the  node  is  appropriately  connected  with  (predecessor  and/or  succes¬ 
sor)  any  standard  test  bus,  shown  in  Paragraph  3.3.  If  this  is  true,  mark  the 
node  as  Tgroup  =  EL.  If  illegal  connections  are  found,  then  the  tool 
searches  for  valid  subsets. 

A  standard  bus  structure  contains  a  JTAG/ETM  support  module,  primary 

inputs/outputs,  or  a  maintenance  node  at  the  head  and  tail  of  the  structure. 

This  case  includes  the  following  configurations: 

1.  ETM  and  JTAG  (rings  and  stars). 

2.  JTAG/ETM  with  sin  — >  sout  pins  connected  in  chains.  Tscan  must 
either  be  set  to  “JTAG”,  “VHSIC”,  or  “ETM”  to  be  considered. 

3.  Single  nodes  can  form  a  star  or  ring,  but  they  become  indistinguishable 
from  each  other. 

i.  If  the  node  is  connected  with  any  BIT  support  modules  (Tbit  of  the  support 
node  is  “BITJPS”,  or  “BIT_DT”,  but  not  Tnode_type  =  scan  mark  the 
node  as  Tgroup  =  EL.  If  the  BIT  support  module  supports  a  pseudorandom 
technique  (i.e.,  BILBO  or  LFSR,  Tbit  =  BIT_PS)  then  recommend  Ttest  = 
PS,  else  Ttest=DT.  If  a  node  is  connected  to  multiple  BIT  support  modules 
and  the  Tbit  values  are  inconsistent,  a  message  is  issued  and  the  node’s 
Tgroup  and  Ttest  are  not  set.  Nodes  considered  are  direct  predecessors  and 
successors. 

j.  If  the  node  has  SCAN  capabilities  (see  if  Tscan  =  etm,  jtag,  scan,  scann- 
able,  vhsic,  y,  yes),  and  it  is  connected  with  other  SCAN  chips  through  a 
valid  chain,  mark  the  node  as  Tgroup  =  IS_scan,  where  “scan”  is  unique. 
Tconfig  will  also  =  IS_scan.  If  the  node  is  not  in  a  valid  chain,  then  suggest 
that  the  user  connects  all  the  SCAN  modules  to  a  chain(s).  Any  scan  support 
modules  (Tbit=BIT  or  “yes”)  connected  in  the  chain  will  be  isolated  in  the 
same  ambiguity  group  with  the  scannable  nodes.  A  valid  chain  is  one  which 
begins  in  and  ends  in  a  maintenance  node  Tbit  =  mn,  m_n,  maintenance 
or  a  primary  input  and  output.  Each  node  must  have  an  inport  with 
inport_id  =  datain,  scanin,  sdi,  sin  and  an  outport  with  outport_id  = 
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dataout,  scanout,  sdo,  sout.  These  chains  can  contain  a  combination  of 
Tscan  =  etm,  jtag,  vhsic  nodes. 

k.  If  the  node  has  BIT  implemented  on  it  (Tbit  is  PS  or  DT)  then  mark  the  node 
as  Tgroup  =  EL.  If  the  BIT  scheme  is  a  pseudorandom  one,  mark  the  node 
as  Ttest  =  PS,  else  mark  it  as  Ttest  =  DT. 

l.  If  the  node  has  (user-provided)  test  patterns  (Tfault_cov  =  100)  and  the 
inputs  and  the  outputs  of  the  node  are  directly  accessible  from  the  primary 
inputs  and  the  primary  outputs  of  the  board,  then  mark  the  node  as  Tgroup 
=  EL,  Ttest  =  DT.  If  the  inputs  or  the  outputs  are  not  directly  accessible, 
and  if  this  node  is  large  (size  >  2*®  =  65536)  then  mark  it  as  Tgroup  =  IS, 
Ttest  =  DT.  Directly  accessible  means  that  all  inports  and  outports  have  to 
be  primary  inputs  or  primary  outputs  by  setting  (see  Tdft_io)  the  arcs  or  by 
setting  the  board  names. 


Size  =  (gates) 

where  gates  is  stored  in  attribute  Thw_module  and  states  is  stored  in  attri¬ 
bute  Tstates. 

m.  If  it  is  a  large  node  (i.e.,  Tnode_type  =  processor  or  VHSIC,  or  size  indicates 
large)  with  no  test  patterns  available  (Tfault_cov  is  not  100),  mark  the  node 
as  Ttest  =  DK.  In  this  case  the  too!  will  suggest  PS  techniques  for  the  data 
lines,  and  DT  techniques  for  the  control  lines.  Also  the  node  is  marked  as 
Tgroup  =  IS_ag  (make  inputs,  outputs  of  the  directly  accessible  at  the 
board  pins).  A  warning  will  be  issued. 

n.  If  the  node  is  asynchronous  (see  Tasynch)  mark  it  as  Tgroup  =  EL,  Ttest 
=  DK  (Scannable  asynchronous  nodes  have  already  been  eliminated.). 

o.  If  the  node  is  a  single  gate  or  a  collection  of  single  gates  (i.e.,  glue  logic),  mark 
it  as  Ttest  =  DC,  Tgroup=  NC.  Use  Tnode_type  or  Tnode_spec_type 
=  glue  or  gate  or  Thw_module  <=  25  to  identify  these  nodes. 
Tnode_type  or  Tnode_spec_type  =  gate  or  glue  will  trigger  this  rule. 
These  nodes  will  eventually  be  combined  with  neighboring  nodes. 

p.  Mark  memory  nodes  (Use  Tnodc_type)  as  Ttest  =  DC,  Tgroup  = 
IS_mein.  This  indicates  that  memories  will  be  tested  separately  as  logical 
groups  with  either  PS  or  DT  test  patterns. 

q.  If  the  node  is  combinational  (see  Tlogic_type)  with  less  than  17  input  data 
lines,  then  mark  the  node  as  Ttest  =  PS,  Tgroup  =  NC  (exhaustive  test¬ 
ing  can  be  accomplished  in  this  case). 

r.  If  none  of  the  above  applies  to  the  node  under  test,  mark  the  node  as  Tgroup 
=  NC  and  then  use  the  BRT  library  to  identify  a  testing  methodology.  Use 
Tnode_type  and  Tnode_spec_type  to  index  into  the  library.  See  a  later 
section  in  this  Paragraph  for  information  about  setting  up  this  library.  Both 
the  Tnode_type  and  the  Tnode_spec_type  of  the  node  must  match  a 
library  entry  to  have  it  correctly  identified. 
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s.  If  the  user  has  simulation  results  that  indicate  that  the  expected  fault  coverage 
(according  to  the  testing  specification)  is  satisfied  with  the  application  of  less 
than  2^®  test  patterns,  then  mark  the  node  as  Ttest  =  PS.  If  not.  mark  the 
node  as  Ttest  =  DT.  If  Tfault_cov  and/or  Ttest_Ien  is  blank  or  equal  to 
0,  this  rule  is  skipped. 

The  relationship  between  expected  fault  coverage  and  pseudorandom  test 
length  can  be  approximated  with  the  following  exponential  function: 

E.  =(1  -  e-L) 

Evaluate  the  constant  a  from  the  simulation  results  given  by  the  user  (E^,  = 
Tfault_cov  /  100  and  L  =  Ttest_len).  After  evaluating  the  constant  a  we 
evaluate  the  expected  fault  coverage  for  2^®=65536  test  patterns.  If  the  E^,  is 
high  (>  90%),  then  mark  node  as  Ttest  =  PS,  else  mark  node  as  Ttest  = 

DT. 

t.  If  the  sum  of  memory  elements  (see  Tstates)  and  the  input  lines  in  a  sequen¬ 
tial  node  is  less  than  or  equal  to  16,  then  mark  the  node  as  Ttest  =  PS  (pseu- 
doexhaustive  testing).  If  a  node  has  no  other  attributes  other  than  Tboard 
and  Tsubsystem  set,  this  rule  applies.  The  node  will  be  considered  not  large 
and  sequential. 

u.  If  none  of  the  above  applies,  then  mark  the  node  Ttest  =  DT. 

The  input  to  the  remaining  modules  is  the  set  of  valid  nodes  that  must  be  assigned  to 
ambiguity  groups  and  the  maximum  ambiguity  group  size. 

CONNECTIVITY  MAP  PROCEDURES 

The  connectivity  map  procedures  take  an  ADAS  hardware  graph  and  generate  a  con¬ 
nectivity  map  in  memory  that  summarizes  the  connections  between  the  valid  nodes  (as 
a  result  of  REMOVE  NON- VALID  NODES).  This  connectivity  map  describes  which 
nodes  are  connected  to  each  node  by  DATA  arcs  and  by  how  many  input  and  output 
arcs.  This  information  is  then  used  to  generate  the  ambiguity  groups  and  calculate 
their  associated  cost  factors. 
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For  every  node  in  the  valid  node  set 
Enter  it  in  the  connectivity  map 
Find  all  the  DATA  successors  of  this  node 

Count  the  number  of  input  arcs  to  each  successor  from  this  node 
Enter  them  in  the  connectivity  map 
Find  all  the  predecessors  of  this  node 

Count  the  number  of  output  arcs  from  each  predecessor  to  this  node 
Enter  them  in  the  connectivity  map 

For  every  node  in  the  connectivity  map 
Assign  it  a  graph  number 

Recursively  assign  this  graph  number  to  every  node 
to  which  this  one  is  connected 

Construct  a  node  set  for  each  disconnected  graph 

AMBIGUITY  GROUP  GENERATOR 

The  ambiguity  group  generator  is  not  run  if  AG_SIZE  =  0  or  1  or  if  there  are  no  valid 
nodes  left  to  group.  A  value  of  zero  for  AG_SIZE  makes  the  largest  groups  possible  on 
the  board.  Non-positive  and  non-integer  values  for  AG_SIZE  are  prohibited. 

This  module  generates  a  list  of  all  groups,  without  known  testability  problems  of  the 
size  given  and  less.  This  list  contains  each  group’s  name,  cost,  list  of  nodes  in  the 
group,  size,  graph  number,  and  AG  mask.  (The  AG  mask  has  a  bit  set  for  each  node 
that  is  in  the  group.  The  bit  is  determined  from  where  the  node  occurs  in  the  valid 
node  set.) 


Generate  the  connectivity  map 

From  the  connectivity  map,  generate  a  list  of  all  groups  of  size  1 
From  the  list  of  groups  of  size  n,  generate  a  list  of  groups  of  size  n-fl 
For  each  group 

For  each  node  in  the  group 

Find  the  node  in  the  connectivity  map, 
and  which  nodes  are  connected  to  it 
If  a  connected  node  is  not  already  in  the  group, 
add  it  to  the  group 
check  testability 

If  ok,  insert  this  group  in  the  new  list 
Calculate  this  group’s  cost  and  ag  mask 
give  it  a  name 

Link  the  size  n-|-l  list  onto  the  beginning  of  the  size  n  list 

The  guidelines  used  to  form  groups  are  stated  here 

a.  Nodes  in  an  ambiguity  group  are  connected  via  data  lines.  The  Tarc_type 
attribute  is  used  to  define  a  line  as  data,  control,  or  clock.  Nodes  only 
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connected  by  control  or  clock  lines  do  not  represent  possible  connected  nodes. 
The  direction  of  flow  of  the  line  is  not  considered. 

b.  Maintain  special  ambiguity  groups  {i.e.,  nodes  marked  as  Tgroup  = 
IS_ag_name  should  be  in  the  Tsp_ag_name  =  “ag_name’'  ambiguity  group). 

c.  Number  of  nodes  in  an  ambiguity  group  is  limited  to  the  user’s  maximum. 

d.  Optimize  choice  of  ambiguity  groups  so  that  “cost  of  overhead”  is  minimized. 
This  “cost”  is  an  integer  assigned  to  represent  the  relative  ease  of  testing  that 
particular  group.  Some  groups  will  be  eliminated  due  to  “poor  testability”. 
These  include 

1.  multiple  DK  (Ttest)  nodes  in  the  same  group 

2.  mixture  of  DK  and  DT  nodes  in  the  same  group 

3.  mixture  of  DK  and  PS  hard-to-test  nodes  in  the  same  group 

4.  mixture  of  DT  and  PS  hard-to-test  nodes  in  the  same  group 

5.  multiple  PS  hard-to-test  nodes  in  the  same  group 

Hard-to-test  nodes  are  nodes  whose 

1.  Ttest_len  >  60,000  or 

2.  Size  >  2^® 

The  possible  ambiguity  groups  are  computed  individually  by  the  user-supplied 
AG_SIZE.  Selecting  an  AG_SIZE  of  ‘3’  will  produce  possible  ambiguity  groups  of  size 
3,  2,  and  1.  Each  possible  ambiguity  group  has  a  particular  “cost”  associated  with  it. 
This  “cost”  represents  the  relative  value  of  the  group  in  term  of  testability.  Groups 
having  the  higher  cost  values  are  groups  which  are  less  desirable  than  those  groups 

with  smaller  cost.  The  ambiguity  group  algorithm  finds  the  configuration  of  possible 

ambiguity  groups  which  represents  the  least  possible  cost.  The  solution  must  contain 
all  nodes  on  the  board. 

The  initial  cost  of  a  possible  ambiguity  group  is  calculated  by  determining  the  sum  of 
output  arcs  which  leave  the  group  and  terminate  in  some  other  group  on  the  current 
board  of  interest.  The  Tarc_type  attribute  is  not  used  when  computing  the  number 
of  output  arcs  leaving  a  group.  From  this  initial  cost,  the  group  cost  may  be  modified 
if  certain  known  testability  features  are  present. 

A  group’s  cost  is  modified  only  when  it  can  be  determined  that  the  group  is  unusually 
hard  or  easy  to  test.  Several  generalizations  have  been  made  concerning  testability 
features  and  their  relationship  with  a  possible  ambiguity  group. 

a.  A  group  which  contains  feedback  eliminates  the  occurrence  of  at  least  one 
feedback  between  ambiguity  groups.  Feedback  between  ambiguity  groups  sig¬ 
nificantly  increases  the  effort  needed  to  test  the  groups.  All  possible  ambi¬ 
guity  groups  which  contain  feedback  (data  lines  only)  have  their  initial  cost 
DECREASED  by  90%.  This  includes  self-loops  or  nodes  which  use  their  own 
data  output. 

b.  Testing  becomes  easier  when  a  group  contains  all  pseudorandomly  testable 
nodes  and  the  number  of  inputs  to  the  group  is  less  than  or  equal  to  the 
number  of  pins  on  standard  test  module.  All  groups  which  contains  only 
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pseudorandomly  testable  nodes  and  have  <  =  16  Inputs  will  have  their  initial 
cost  DECREASED  by  50%. 

c.  Groups  which  contain  only  glue  logic  are  undesirable.  The  overhead  associated 
with  testing  this  type  of  logic  as  a  group  is  too  significant.  All  possible  groups 
which  contain  only  glue  logic  will  have  their  initial  cost  INCREASED  by  50%. 

If  none  of  these  three  testability  features  are  present  in  the  group,  then  the  cost  is  sim¬ 
ply  the  sum  of  the  outputs  from  the  group  which  terminate  on  the  board.  If  more 
than  one  is  present,  then  the  increase  or  decrease  is  taken  from  the  modified  cost  not 
on  the  original  output  arc  sum. 

The  final  cost  is  an  Integer,  so  after  the  multiplication  of  the  penalty/reward  factor, 
the  result  is  truncated. 

If  any  final  costs  are  >  256,  the  costs  of  all  the  groups  are  normalized  to  be  within  the 
range 

-1  <  X  <  257. 


BRANCH  AND  BOUND 

This  module  finds  the  optimum  configuration  of  the  ambiguity  groups.  An  optimum 
configuration  is  one  where  each  node  is  assigned  to  an  ambiguity  group,  and  the  total 
cost  of  the  ambiguity  groups  is  minimized.  This  module  uses  a  branch  and  bound 
approach,  with  the  lower  bounds  calculated  using  the  simplex  method.  A  node  list  is 
generated  that  lists  which  ambiguity  groups  contain  each  node.  This  list  is  ordered  by 
the  nodes  that  are  in  the  smallest  number  of  AGs  first.  There  are  no  duplicate  ambi¬ 
guity  groups  in  this  list.  Hashing  is  used  to  speed  this  process. 

Branch  and  bound  must  be  run  on  each  disconnected  graph  representing  the  board. 


Generate  the  node  list 

For  each  group  that  the  first  node  is  in,  calculate  a  lower  bound  on  the 
cost  if  this  group  is  used  in  the  configuration 
Branch  using  the  group  with  the  lowest  bound 

For  the  next  node  in  the  list  that  hasn’t  been  covered  by  an  ambiguity 
group,  calculate  lower  bounds 
Branch  using  the  group  with  the  lowest  bound 

This  continues  until  a  solution  configuration  is  found,  or  it  is  determined 
that  this  configuration  will  not  yield  a  valid  solution 
Backtrack,  to  try  and  find  a  better  solution  configuration 

Note:  The  branch  routine  does  not  choose  a  branch  where  the  lowest  bound  is  greater 
that  a  solution  obtained  so  far.  This  “branch  and  bound  tree  pruning”  saves  a  signifi¬ 
cant  amount  of  time,  as  compared  with  a  brute  force  “branch”  tree.  Valid  solutions 
have  each  valid  node  assigned  to  one  and  only  one  ambiguity  group  which  is  con¬ 
nected. 
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SIMPLEX  METHOD 


This  module  solves  a  linear  program.  It  uses  the  revised  simplex  method  with  the 

explicit  form  of  the  inverse  and  the  lexico  minimum  ratio  rule  to  avoid  cycling. 

(Cycling  is  very  prominent  in  set  partitioning  problems.) 

ASSIGN  TEST  METHOD  TO  AGs 

After  the  division  of  nodes  into  ambiguity  groups,  brt  assigns  a  testing  method  (PS. 

DT,  or  DK)  to  each  AG.  Only  nodes  with  Tag_name  or  Tsp_ag_name  set  to  some 

value  are  considered. 

The  following  tests  are  performed  in  order 

a.  If  an  ambiguity  group  has  any  node(s)  that  is(are)  deterministically  testable, 
then  the  AG  is  DT  testable,  Tag_test  =  DT. 

b.  If  the  AG  consists  of  one  or  more  nodes  marked  as  DK,  then  the  AG  is  marked 
as  Tag_test  =  DK.  A  recommendation  to  test  this  AG’s  data  lines  psea- 
doraudomly  and  control  lines  deterministically  will  be  issued. 

c.  If  the  ambiguity  group  has  an  embedded  large  (size  >  2^^)  PS  node,  most  >  = 
90%  of  the  inputs  or  the  outputs  of  this  node  are  not  accessible  from  the 
inputs  or  the  outputs  of  the  AG)  which  is  close  to  the  pseudorandom  limit 
(i.e.,  Ttest_len,  is  greater  than  60,000  test  patterns),  then  mark  AG  as 

Tag_test  =  DT. 

d.  An  AG  is  marked  as  Tag_test  =  DT  if  any  large  (size  >  2^®)  nodes  are 
marked  as  Ttest  =  PS,  and  they  have  test  lengths  greater  than  the  pseu¬ 
dorandom  limit  (e.g.,  64,000).  A  warning  should  be  given  to  the  user  in  this 
case  since  the  last  statement  is  not  absolutely  true  (fault  simulation  is  required 
for  this  case).  All  other  groups  with  PS  nodes  will  be  marked  Tag_test  = 
PS. 

e.  If  all  nodes  in  an  AG  are  Ttest  =  DC,  then  assign  test  method  of  adjoining 
AG  to  this  AG.  The  first  AG  attached  to  the  output  of  this  AG  which  has 
Tag_test  set,  will  be  used  unless  there  is  no  succeeding  AG.  If  there  is  no 
succeeding  AG,  then  the  Tag_test  of  the  preceding  AG  is  used.  If  there  are 
no  other  AGs,  Tag_test  is  set  to  PS. 

Size  of  a  Node 

The  size  of  the  chip  in  terms  of  sequential  complexity  is  defined  as: 

Size  =  (gates) 

where  gates  is  stored  in  attribute  Thw_module  and  states  is  stored  in  attribute 

Tstates.  Size  is  needed  to  determine  when  a  node  is  “large”,  or  Size  >=  2^®.  If  either 

Thw_module  or  Tstates  has  a  null  value,  a  node  is  not  considered  “large.” 
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BRT  Library 

The  purpose  of  the  BRT  library  is  to  provide  the  user  with  test  attribute  information 
for  different  structures.  The  library  should  have  the  following  entries 

a.  The  character  starts  each  record.  It  should  appear  as  the  first  and  last 
character  of  the  library  file  on  lines  by  itself.  A  line  with  a  lone  should 
separate  each  record. 

b.  Node  Identifier:  This  entry  will  contain  the  name  of  the  circuit,  as  well  as  any 
aliases  that  represent  similar  structures  (Tnode_type). 

c.  Identifying  Number:  Specific  device  types  (Tnode_spec_type). 

d.  Testing  recommendation:  Possible  entries  are  DT,  PS,  or  DC  (Ttest). 

e.  Test  Length:  Number  of  test  vectors  that  give  the  fault  coverage  specified  in 
the  next  entry  {Ttest_len). 

f.  Fault  Coverage:  This  entry  is  used  in  conjunction  with  the  test  length  to  deter¬ 
mine  whether  a  node  is  pseudorandomly  testable  or  not  (Tfault_cov). 

g.  References  -  Comments:  This  field  gives  information  to  the  user  concerning 
the  entries  specified  in  other  fields,  and  the  references  from  which  these  results 
where  obtained. 

h.  The  character  starts  each  record.  It  should  appear  as  the  first  and  last 
character  of  the  library  file  on  lines  by  itself.  A  line  with  a  lone  should 
separate  each  record. 

Tnode_type  and  Tnode_spec_type  of  a  node  must  each  match  one  of  the  entries  on 
lines  1  and  2  of  the  record.  Tnode_spec_type  matches  line  2  if  both  are  null  strings. 
If  the  library  record  matches  a  node,  then  Ttest  is  set  to  the  value  found  on  line  3, 
Tfault_cov  is  set  to  the  value  found  on  line  4,  and  Ttest_len  is  set  to  the  value 
found  on  line  5. 
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Example  BRT  Library 


name 

specname 

test 

test  len 

fault  cov 

comments 

PLA 

DT 

special  PLAs  may  be  PS 

adder 

PS 

100 

100 

independent  of  input  lines 

multip 

25s05 

PS 

•200 

100 

4x2  cascadable  modules 

12x6  (9  modules)  200  pat:  93% 

alu 

xxlSl 

PS 

180 

100 

4-bit  alu  (xx:  74,54,40) 

counter 

xxl63 

PS 

50 

100 

control  lines  DT 

compar 

xx85 

PS 

20 

100 

independent  of  input  lines 

encoder 

PS 

100 

100 

independent  of  input  lines 

decoder 

PS 

100 

100 

independent  of  input  lines 

mux 

PS 

100 

100 

independent  of  input  lines 

regist 

xxl74 

PS 

50 

100 

independent  of  input  lines 

shft-re 

PS 

200 

100 

independent  of  input  lines 

multi 

1010 

PS 

100 

93 

16x16  Booth’s  algorithm 

parity 

xxl80 

PS 

60 

100 

independent  of  input  lines 

Example  BRT  library  file  (tea_brt  contains): 

The  record  delimiters  (%)  are  necessary.  To  find  an  entry  in  the  BRT  library, 
Tnode_type  and  Tnode_spec_type  must  match. 


% 

PLA 

DT 


special  PLAs  may  be  PS 

% 

adder 

PS 

100 

100 

independent  of  input  lines 

% 

multip 

25s05 

PS 

200 

100 

4x2  cascadable  modules 

% 

Another  example  showing  multiple  values  possible  for  Tnode_type  and 
T  node_spec_ty  pe. 

% 

two  2  second 
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2  to  too 
PS 
88 
50 

just  an  example 

% 

Limitations. 

ADAS  data  base  graphs  must  already  have  been  created  before  TEA  is  entered. 

Biports  are  ignored. 

TEA  supports  the  concept  of  .\DAS  buses,  but  all  buses  are  assumed  to  be  a  single  bit 
in  width. 

Outputs. 

The  Tag_nanie,  Ttest,  Tgroup,  and  Tconfig  attributes  will  be  reset  at  the  start  of 
execution  and  will  be  set  by  the  process.  Tag_name  holds  the  value  of  the  ambiguity 
group  to  which  the  process  assigns  the  node.  Tconfig  holds  the  name  of  any  special 
configuration  to  which  the  node  belongs,  as  identified  by  the  process. 

At  the  completion  of  brt,  a  report  is  generated  to  itemize  the  ambiguity  groups  and 
the  testing  methodology  assigned  to  them. 

Using  the  rules  that  find  special  testing  situations,  messages  are  issued  in  the  following 
cases 

a.  If  any  of 

1.  BIT  modules 

2.  nodes  with  BIT 

3.  selftestable  nodes 

4.  scannable  VHSIC  nodes 

exist  on  a  board,  output:  “Make  sure  all  BIT  modules,  nodes  with  BIT,  selfte¬ 
stable  nodes,  and  scannable  VHSIC  nodes  have  accessible  control  lines  and 
observable  output  lines.” 

b.  If  no  selftestable  nodes  exist,  output:  “No  selftestable  nodes  were  found  on 
board  “xyz.”  Use  attribute  Tselftest  to  indicate  selftestable  nodes.” 

c.  If  no  chips  with  BIT  exist,  output:  “No  nodes  with  BIT  were  found  on  board 
“xyz.”  Use  attribute  Tbit  to  indicate  nodes  with  BIT.” 

d.  If  no  scannable  nodes  exist,  output:  “No  scannable  nodes  were  found  on 
board  “xyz.”  Scannable  nodes  should  be  used  when  possible  because  they 
increase  testability.  Use  attribute  Tscan  to  indicate  scannable  nodes.” 

Following  is  an  example  of  the  output  from  brt  with  AG_SIZE  set  to  4.  The  report 
has  many  sections,  including  the  itemization  of  special  testing  situations.  After  all  spe¬ 
cial  cases  have  been  itemized,  a  list  of  the  remaining  nodes  that  will  be  assigned  to 
ambiguity  groups  is  shown.  Here,  there  are  17  nodes  to  be  assigned.  Following  this 
list  is  the  output  and  statistics  from  the  “AMBIGUITY  GROUP  GENERATOR”  code. 
In  this  example  there  are  three  disconnected  graphs,  and  a  solution  has  been  found  for 
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each  one  (Since  ambiguity  groups  must  be  connected  by  arc_type  =  DATA  arcs, 
disconnected  graphs  are  not  uncommon.)  graph.  Graph  1  has  chosen  nodes  T2lb. 
T21a,  Tl9b,  and  Tl9a  to  be  in  ambiguity  group  “AG47”,  or  Tag_name  =  AG47  and 
nodes  Tl5d,  Tl5c,  Tl5b,  and  Tl5a  to  be  in  ambiguity  group  “AG43”.  or  Tag_name 
=  AG43.  Graph  2  only  had  one  node  and  this  was  assigned  to  ambiguity  group 
“AG9”.  Graph  3’s  eight  nodes  were  assigned  to  ambiguity  groups  -‘AGdb”  and 
“AG46”.  The  cost  of  graph  I’s  division  is  one,  the  cost  of  graph  2’s  division  is  four, 
and  the  cost  of  graph  3’s  division  is  one.  This  will  result  in  a  total  cost  of  six  test 
points  or  observable  arcs. 
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***Insert  STANDARD  HEADER  here*** 


BIT  RECOMMENDATION 
(brt) 

BRT  will  divide  the  nodes  on  subsystem  ’phasel’, 
board  ’plthree’  into  ambiguity  groups  of  size  ’4’  or  less. 

Modified  cost  function  will  be  minimized. 

Found  a  valid  scan  chain 
TSmixa 
TSmixb 
TSmixc 

Found  a  valid  ETM  star  configuration 
TSeSa 
TSeSb 
TSeSc 
TSeSd 

Found  a  valid  ETM  ring  configuration 
TSeRa 
TSeRb 
TSeRc 
TSeRd 

Found  a  valid  JTAG  star  configuration 
TSjSa 
TSjSb 
TSjSc 

Found  a  valid  JTAG  ring  configuration 
TSjRa 
TSjRb 
TSjRc 

Found  a  valid  scan  chain 
TlOa 
TlOb 
TlOc 

Node  ’T6b’  is  a  scan  support  and  should  be  properly  connected 
Node  ’T6a’  is  a  scan  support  and  should  be  properly  connected 
Node  ’TSjsup’  is  a  scan  support  and  should  be  properly  connected 
Node  ’TSetmsup’  is  a  scan  support  and  should  be  properly  connected 

Make  sure  all  BIT  modules,  nodes  with 
BIT,  selftestable  nodes  and  scannable 
VHSIC  nodes  have  accessible  control 
lines  and  observable  output  lines. 

No  selftestable  nodes  were  found  on  this  board. 

Use  attribute  Tselftest  to  indicate 
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selftestable  nodes. 


Removing  special  AG  nodes 
T4c 
T4b 
T4a 

Removing  maintenance  nodes 
T4a 
T8mnc 
T8mn 
TlOmn 
T8mnb 

Removing  JTAG/ETM  support  nodes 
T6b 
T6a 
T8jsup 
T8etmsup 

Removing  JTAG/ETM  rings,  stars  and  scan  chain  nodes 
T8mixa 
T8jSa 
T8jRa 
T8eSa 
T8eRa 
TSmixb 
T8jSb 
T8jRb 
T8eSb 
T8eRb 
TSmixc 
T8jSc 
T8jRc 
T8eSc 
T8eRc 
T8eSd 
T8eRd 

Removing  SCAN  nodes  in  valid  scan  chains 
TlOa 
T8mixa 
TlOb 
T8mixb 
TlOc 
T8mixc 

Removing  asynchronous  nodes 
T4b 
T8mixa 
T8jSa 
T8jRa 
T8eSa 
T8eRa 
T8mixb 
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T8jSb 

T8jRb 

T8eSb 

T8eRb 

T8mixc 

TSjSc 

T8jRc 

T8eSc 

T8eRc 

T8eSd 

T8eRd 

Removing  memory  nodes 
T6a 

These  nodes  will  be  assigned  to  ambiguity  groups. 

T21b 

T21a 

Tl9b 

Tl9a 

Tl5d 

Tl5c 

T15b 

T15a 

T8POb 

notTlS 

T18c 

T18b 

T18a 

T20c 

notT20 

T20a 

T20b 

There  are  53  possible  ambiguity  groups  of  size  4  or  smaller. 

- graph  #1  of  3  Thu  Oct  13  10:41:18  1988 

Optimal  configuration  has  cost  function  value  =  1: 

Number  of  output  lines  =  1: 

The  Tag_name  attribute  has  been  set  for  the  following  nodes: 

(output_lines,cost_fcn_value)  ambiguity_group:  nodes_in_AG 
(0,0)  AG49:  T21b  T21a  Tl9b  Tl9a 
(1,1)  AG44:  Tl5d  Tl5c  Tl5b  Tl5a 


_ graph  #2  of  3  Thu  Oct  13  10:41:19  1988 

Optimal  configuration  has  cost  function  value  =  14: 

Number  of  output  lines  =  14: 

The  Tag_name  attribute  has  been  set  for  the  following  nodes: 

(output_lines,cost_fcn_value)  ambiguity_group:  nodes_in_AG 
(14,14)  AG9:  T8POb 
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- graph  #3  of  3  Thu  Oct  13  10:41:19  1988 

Optimal  configuration  has  cost  function  value  =  1: 

Number  of  output  lines  =  1: 

The  Tag_name  attribute  has  been  set  for  the  following  nodes: 

(output_lines,cost_fcn_value)  ambiguity_group:  nodes_in_AG 
(0,0)  AG48:  notTlS  Tl8c  Tl8b  Tl8a 
(1,1)  AG47:  T20c  notT20  T20a  T20b 


Start  time  =  Thu  Oct  13  10:41:12  1988 

Finish  time  =  Thu  Oct  13  10:41:19  1988 

Total  configuration  cost  =  16 
Total  ^  of  output  lines  =  16 


Test  methods  set  for  each  AG 


AG44 

PS 

AG47 

DT 

AG48 

DT 

AG49 

DT 

AG9 

DT 

group  1 

PS 

groups 

DK 

**ttiiitititit**********tit******************it***»********* 

Note  to  user:  Use  compare  to  get  a  listing  of  the  nodes  in  each  ambiguity  group. 

To  affect  the  groups  themselves,  use  ag_name  to  set  special  ambiguity  groups  and  rerun  BRT 

Supported  off-line  BIT  techniques 

1.  Continuous  test  point  monitoring  (det_tp) 
supports  PS  and  DT  strategies 

2.  Test  point  monitoring  with  data  compression 
(tp_sa)  supports  PS  strategies  on 

input  data  lines. 

3.  Board  level  boundary  ."'■au  (boundary)  supports 
DT  strategies. 

4.  Scan-set  supports  both  PS  and  DT  strategies. 

5.  Test  pattern  generation  with  data  compression 
(gen_sa)  supports  both  PS  and  DT  techniques. 

PS  =  Pseudorandomly  generated  test  pattern 
DT  =  Deterministically  generated  test  pattern 

brt  completed 


Error  Message /Action. 
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Message 

Action 

Node  name  had  Tag_name 

No  action  required 

and  Tsp_ag_name  set. 

Tag_name  cleared 

Additional  Information. 

See  paragraphs  describing 

a.  data  base  attributes  and  valid  syntaxes  (Paragraph  2.3.2) 

b.  results.tmp  file  (Paragraph  2.6.2.1) 

c.  special  ambiguity  groups  (Paragraph  2.6.3) 

d.  output  report  header  (Figure  2-5) 

e.  standard  test  buses  (Paragraph  3.3) 

Brt  should  be  used  iteratively.  The  results  from  the  tool  are  enhanced  by  user  input 
about  specific  groupings  (i.e.,  special  ambiguity  groups)  and  AG  size.  By  using  special 
AGs,  the  user  can  speed  up  the  execution  of  brt  by  eliminating  some  possible  groups 
because  nodes  can  only  be  assigned  to  a  single  AG. 


2.7.3.  BIT  Overhead  Summary  (bit  cost).  The  BIT  Overhead  Summary  (bit_cost) 
process  advises  the  user  on  the  hardware  overhead  costs  to  implement  a  particular 
design  for  testability  /  built-in  test  technique  given  a  set  of  ADAS  graphs  describing  a 
digital  hardware  board. 

Paragraph  3.4.2  describes  each  of  the  five  BIT  techniques  that  are  implemented  as  part 
of  bit_cost.  The  five  techniques  include 

a.  continuous  test  point  monitoring, 

b.  test  point  monitoring  with  compressed  data, 

c.  board  level  boundary  scan, 

d.  scan-set,  and 

e.  test  pattern  generation  with  signature  analysis. 

Paragraph  3.4.3  describes  the  TEA-supplied  BIT  modules,  available  as  ADAS  tem¬ 
plates  and  implemented  in  VHDL.  These  include 

a.  scan-set  register, 

b.  programmable  feedback  pseudorandom  test  pattern  generators, 

c.  built-in  logic  block  observer  (BILBO), 

d.  testing-switch  (TSWITCH),  and 

e.  an  example  maintenance  node. 
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Inputs. 


The  user  must  supply  the  board  and  subsystem  names  and  the  BIT  technique(s)  to  be 
considered. 

Processing. 

The  following  paragraph  presents  the  high-level  algorithms,  special  control  features, 
and  error  handling  features  of  bit_cost. 


Get  user_input(Tsubsystems) 

Get  user_input(Tboards) 

Get  user_input(technique(s)) 

F or  each  technique 

If  (technique  !=  3) 

Find  ambiguity  group  boundaries 
Apply  technique(s) 

Accumulate  costs 
Output  report 
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Accumulate  Costs 


Technique 

Name 

Costs 

1-5 

Add  3  control  inputs 
for  reset,  tphil,  tphi2 
if  any  modules  ad¬ 
ded.  Add  a  Mainte¬ 
nance  Node. 

1* 

continuous  test  point 
monitoring  (det_tp) 

Add  test  points  as 
necessary. 

2* 

test  point  monitoring 
with  data  compres¬ 
sion  (tp_sa) 

Add  8  control  inputs 
and  1  test  outputs 
per  BILBO.  Add  5 
control  inputs  and  1 
test  outputs  per  Test 
Pattern  Generator. 
Add  2  control  inputs 
for  any  2x16  Multi¬ 
plexors.  Add  2  con¬ 
trol  inputs  for  each 
4x16  Multiplexor. 

3* 

board  level  boundary 
scan  (det_tp) 

Add  6  control  inputs 
and  2  test  outputs 
per  Scan-Set  module. 

4* 

scan-set  (scanjset) 

Add  6  control  inputs 
and  2  test  outputs 
per  Scan-Set  module. 

5* 

test  pattern  genera¬ 
tion  with  data 

compression  (genjsa) 

Add  16  control  in¬ 
puts  and  2  test  out¬ 
puts  per  Testing 
Switch. 

*Many  of  the  control  inputs  and  outputs  can  be  shared  among  the  BIT  modules.  The 
I/O  overhead  counts  predicted  by  the  bitjcost  are  upper  bounds. 


2-62 


Limitations. 


ADAS  data  base  graphs  must  already  have  been  created  before  TEA  is  entered. 

The  process  only  applies  to  the  five  BIT  techniques  listed  above.  Example  implemen¬ 
tations  of  the  techniques  will  only  use  BIT  modules  listed  in  this  section  or  otherwise 
provided  in  the  supplied  library.  There  are  many  example  implementation  possibili¬ 
ties,  but  only  one  has  been  chosen  for  each  of  the  techniques.  Refer  to  Paragraph  .3.4.2 
for  technique  descriptions. 

Biports  are  ignored. 

TEA  supports  the  concept  of  ADAS  buses,  but  all  buses  are  assumed  to  be  a  single  bit 
in  width. 

Test  points  are  not  placed  on  board  outputs. 

Graphs  are  “flattened”  during  bit_cost  execution.  This  may  result  in  BIT  module 
cost  which  is  low  compared  to  what  is  required  for  a  simulation,  due  to  the  require¬ 
ment  of  maintaining  graph  boundaries. 

Outputs. 

At  the  completion  of  bit_cost,  a  report  is  generated  to  itemize  the  costs  of  implemen¬ 
tation  of  the  chosen  technique(s).  A  wiring  diagram  file  is  created  to  show,  in  general, 
how  to  add  modules. 

This  example  output  report  from  bit_cost  itemizes  the  costs  for  selecting  four  of  the 
five  available  techniques,  each  considered  individually.  The  user  is  directed  to  the  sec¬ 
tions  describing  the  BIT  techniques  and  supporting  modules  (Paragraphs  3.4.2  and 
3.4.3).  The  numbers  associated  with  primary  inputs  and  outputs  are  given  assuming 
the  user  controls  each  additional  module  separately  and  externally  from  the  board. 
The  negligible  costs  associated  with  the  “boundary”  technique  result  from  only  having 
one  board  on  the  test  graph.  The  tool  finds  that  it  is  not  necessary  to  add  any  addi¬ 
tional  overhead  to  the  board  to  observe  the  board’s  output.  bit_cost  only  considers 
nodes  that  have  either  Tag_name  or  Tsp_ag_nanie  set. 
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***Insert  STANDARD  HEADER  here*** 


BIT  OVERHEAD  SUMMARY 

(bit_cost) 

The  following  nodes  will  be  considered 
n9 
n2 
nl 
nO 
n4 
n3 
nlO 
n7 
n6 
nS 
nS 

Generating  hardware  overhead  for  subsystem  ’only’,  board  ’first’ 

Counts  for  BIT  technique  ’tp_sa’ 

2  Scan-set  Modules 
0  Testing  Switches 
OTPGs 
1  BILBOs 
0  2x16  Muxes 
1  4x16  Muxes 
0  Test  Points 

25  BIT  Module  Control  Inputs 
5  BIT  Module  Test  Outputs 
1  Maintenance  Node 

Counts  for  BIT  technique  ’boundary’ 

0  Scan-set  Modules 
0  Testing  Switches 
OTPGs 
0  BILBOs 
0  2x16  Muxes 
0  4x16  Muxes 
0  Test  Points 

0  BIT  Module  Control  Inputs 
0  BIT  Module  Test  Outputs 
1  Maintenance  Node 

Counts  for  BIT  technique  ’scan_set’ 

4  Scan-set  Modules 
0  Testing  Switches 
OTPGs 
0  BILBOs 
0  2x16  Muxes 
0  4x16  Muxes 
0  Test  Points 

27  BIT  Module  Control  Inputs 
8  BIT  Module  Test  Outputs 
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1  Maintenance  Node 


Counts  for  BIT  technique  'gen_sa' 

0  Scan-set  Modules 
2  Testing  Switches 
OTPGs 
0  BELBOs 
0  2x16  Muxes 
0  4x16  Muxes 
0  Test  Points 

35  BIT  Module  Control  Inputs 
4  BIT  Module  Test  Outputs 
1  Maintenance  Node 

*4i**«***}|i*4i***«***4ii|i*«****«»»***»*«**x*«««»**«**«*** 

NOTE  to  user: 

If  the  costs  itemized  here  are  excessive,  consider 
fixing  some  of  the  ambiguity  group  partitions  with 
ag_name  and/or  increasing  ambiguity  group  size  and 
rerunning  brt. 

4i  4t  4(  4t  **  4t  *  :^  *****  3|i  **««««  »4<  *««*»*♦*«****  *  * 

bit_cost  completed 
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***Insert  STANDARD  EffiADER  here*** 


BIT  OVERHEAD  SUMMARY 
(bit_cost) 

Wirelist  for  'tp_sa'  on  subsystem  ’only’,  board  ’first’ 
Data  for  AG  ’ag9’ 

Add  on  board  BILBO  line  to  n9/Ol 
Data  for  AG  ’longname’ 

Add  on  board  BILBO  line  to  nl/Ol 
Data  for  AG  ’agbus’ 

Data  for  AG  ’norm’ 

Add  SCAN  line  to  nlO/IO 
Data  for  AG  ’al’ 

Add  SCAN  line  to  n8/I0 

Wirelist  for  ’boundary’  on  subsystem  ’only’,  board  ’first’ 

Wirelist  for  ’scan_set’  on  subsystem  ’only’,  board  ’first’ 

Data  for  AG  ’ag9’ 

Add  output  SCAN  line  to  n9/Ol 
Data  for  AG  ’longname’ 

Add  output  SC.AN  line  to  nl/Ol 
Data  for  AG  ’agbus’ 

Data  for  AG  ’norm’ 

Add  control  input  SCAN  line  to  nlO/10 
Data  for  AG  ’al’ 

Add  data  input  SC.AN  line  to  n8/I0 

Wirelist  for  ’gen_sa’  on  subsystem  ’only’,  board  ’first’ 

Data  for  AG  ’ag9’ 

Data  for  AG  ’longname’ 

Data  for  AG  ’agbus’ 

Data  for  AG  ’norm’ 

Add  control  input  TSWITCH  line  to  nlO/IO 
Data  for  AG  ’al  ’ 

Add  data  input  TSWITCH  line  to  n8/I0 


bit_cost  completed 


Error  Message /Action. 


Message 

Action 

Node  name  had  Tag_name 

No  action  required 

and  Tsp_ag_name  set. 

Taf_name  cleared 

TPO  count  may  be  exaggerated 

No  action  required 

due  to  fanout 

Additional  Information. 

See  paragraphs  describing 

a.  data  base  attributes  and  valid  syntaxes  (Paragraph  2.3.2) 

b.  results.tmp  file  (Paragraph  2.6.2.1) 

c.  output  report  header  (Figure  2-5) 

d.  BIT  techniques  (Paragraph  3.4.2) 

e.  BIT  modules  (Paragraph  3.4.3) 


2.7.4.  BIT  Placement  Recommendation  (placebit).  The  BIT  Placement  Recommenda¬ 
tion  (placebit)  process  advises  the  user  on  how  to  implement  a  particular  design  for 
testability  /  built-in  test  technique  given  a  set  of  ADAS  graphs  describing  a  digital 
hardware  board.  This  advice  can  take  three  forms 

a.  general  instructions  for  the  chosen  technique  without  specific  implementation 
information  about  modules  needed,  I/O  lines  needed,  or  the  current  view  data 
base 

b.  a  wiring  list  from  which  the  user  can  manually  update  his  ADAS  graphs  to 
implement  the  TEA  example  implementation  (using  TEA-supplied  library  BIT 
modules)  of  the  chosen  technique 

c.  ADAS  graphs  which  are  updated  to  show  the  example  implementation  of  the 
chosen  technique 

In  this  latter  case,  library  BIT  modules  are  “plopped”  onto  the  graph  and  appropriate 
internal  data,  control,  and  clock  lines  are  routed  as  best  as  possible  for  the  user.  For 
either  of  the  two  latter  options,  each  of  the  modules  on  the  selected  board  must  be 
assigned  to  an  ambiguity  group  (for  BIT  techniques  1,  2,  4,  and  5).  This  implies  that 
the  user  manually  sets  the  attributes  Tsp_ag_name  and  Tag_name  using  ag_name 
(see  Paragraph  2.6.1)  and/or  automatically  sets  the  attributes  using  brt  (see  Para¬ 
graph  2.7.2). 

Paragraph  3.4.2  describes  each  of  the  seven  BIT  techniques  that  are  implemented  as 
part  of  TEA.  The  seven  techniques  include 

a.  continuous  test  point  monitoring 
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b.  test  point  monitoring  with  compressed  data 

c.  board  level  boundary  scan 

d.  scan-set 

e.  test  pattern  generation  with  signature  analysis 

f.  parity  generation/checking 

g.  on-line  comparison  of  duplicated  modules 

Paragraph  3.4.3  describes  the  TEA-supplied  BIT  modules,  available  as  ADAS  tem¬ 
plates  and  implemented  in  VHDL.  These  include 

a.  scan-set  register 

b.  programmable  feedback  pseudorandom  test  pattern  generators 

c.  built-in  logic 

d.  testing-switch 

e.  an  example  maintenance  node 

f.  9-bit  parity  generator/checker 

g.  8-bit  equal  comparator 
Inputs. 

The  user  must  specify  the  subsystem  and  board  names  and  the  technique  to  use. 
Processing. 

The  following  paragraph  presents  the  high-level  algorithms,  special  control  features, 
and  error  handling  features  of  placebit. 


IF  (OUTPUT  =  general) 

Supplyinfo  (TECHNIQUE) 

Goto  EndOiFlacebit 

IF  (TECHNIQUE  =  8)  /*  parity  generation/checking  */ 

GetReadyFor  (TECHNIQUE) 

ELSEIF  (TECHNIQUE  =  7)  /•  comparison  */ 

GetReadyFor  (TECHNIQUE) 

/*  check  for  special  graph  concerns  including  boundary 
scannable  parts,  YHSIC  parts,  and  asynchronous  logic  * / 

ELSEIF  (TECHNIQUE  <  6) 

Startup  (TECHNIQUE) 

IF  (OUTPUT  =  wirelist) 

DoWireList  (TECHNIQUE) 

IF  (OUTPUT  =  autoplace) 

DoAutoPlace  (TECHNIQUE) 

EndOfPlacebit: 

WriteOutputReport  () 

End. 

DoWireList  (TECHNIQUE) 
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Limitations. 

ADAS  data  base  graphs  must  already  have  been  created  before  TEA  is  entered. 

The  process  only  applies  to  the  seven  BIT  techniques  listed  in  this  section.  Example 
Implementations  of  the  techniques  will  only  use  BIT  modules  listed  in  this  section  or 
otherwise  provided  in  the  library.  There  are  many  example  implementation  possibili¬ 
ties,  but  only  one  has  been  chosen  for  each  of  the  techniques. 

The  routine  which  updates  the  .ADAS  graphs  will  not  generally  make  “pretty”  graphs; 
additional  BIT  modules  are  placed  by  a  “first  available  position”  procedure. 

Biports  are  ignored. 

TEA  supports  the  concept  of  ADAS  buses,  but  all  buses  are  assumed  to  be  a  single  bit 
in  width. 

To  minimize  confusion,  it  is  recommended  that  only  one  BIT  technique  of  2,  4,  and  5 
be  added  to  a  particular  board.  To  accomplish  this,  BIT  modules  are  not  assigned  to 
an  ambiguity  group  so  ambiguity  group  boundaries  will  not  be  identified  for  further 
BIT  module  placement. 

Because  board  and  ambiguity  group  boundaries  may  cross  graph  boundaries,  more 
than  the  minimum  number  of  BIT  modules  may  be  added. 

Highly  connected  and  tightly  packed  graphs  will  result  in  extremely  long  run  times, 
placebit  autoplace  is  provided  to  save  the  user  time  in  updating  graphs,  so  it  is  only 
at  the  option  of  the  user  that  autoplace  runs.  A  wirelist  can  be  obtained  in  much 
shorter  time  and  this  can  be  used  to  manually  update  the  graph  with  the  necessary 
BIT  support  modules. 

No  test  points  are  added  at  board  boundaries. 

To  update  a  hardware  graph  data  base,  a  corresponding  “.hwt”  (hardware  template) 
file  is  required. 

Outputs. 

At  the  completion  of  placebit,  a  report  is  generated  to  illustrate  the  options  imple¬ 
mented  and  the  termination  status.  If  the  general  output  option  was  chosen,  the 
report  will  also  contain  a  statement  about  how  to  generally  implement  the  chosen  tech¬ 
nique.  Those  general  statements  are  listed  here. 

Node  and  port  names  are  given  when  possible  to  aid  the  user  in  identifying  structures. 
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General  Output  Messages 


1.  continuous  test 
point  monitoring 
(det_tp) 


2.  test  point  moni¬ 
toring  with  data 
compression  (tpjsa) 


3.  board  level  boun¬ 
dary  scan  (boun¬ 
dary) 


4.  scan-set 

(scanjset) 


Make  all  lines  which 
leave  an  ambiguity 
group  observable  test 
points. 

Provide  pseudoran¬ 
dom  input  vectors  for 
all  primary  input 
data  lines  and  deter¬ 
ministic  input  vectors 
for  all  primary  input 
control  lines.  Break 
feedback  paths 

between  ambiguity 
groups,  such  that  all 
lines  are  settable 
under  test  control. 
To  get  better  access 
to  internal  ambiguity 
groups,  also  break  all 
fanout  lines  between 
ambiguity  groups. 
All  lines  which  are 
ambiguity  group  out¬ 
puts  should  be 
diverted  to  a  signa¬ 
ture  analyzer. 

Place  scannable  regis¬ 
ters  at  all  the  pri¬ 
mary  inputs  to  the 
board. 

Completely  isolate 
ambiguity  groups 
with  scannable  regis¬ 
ters. 
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General  Output  Messages  (Continued) 


5.  test 

pattern  gen- 

Completely 

isolate 

e  rat  ion 

with  data 

ambiguity 

groups 

compression  (gen_sa) 

with  appropriate  test 

pattern 

generators 

and 

analyzers. 

signature 

Place  parity  checker 
or  generator  on  the 
desired  data  lines. 
Choose  either  odd  or 
even  parity. 

7.  on-line  comparis-  Place  the  comparison 
on  of  duplicated  module  such  that  the 
modules  (compare)  lines  to  be  compared 

are  routed  to  it  and 
the  error  flag  output 
is  accessible. 


6.  parity 

check/generate  (par¬ 
ity) 


If  the  wirelist  option  is  chosen,  placebit  will  provide  a  file  with  name  of  the  format 
placebit_n.dwg,  that  provides  instructions  for  manual  update  of  the  ADAS  graphs  to 
accommodate  the  example  implementation  of  the  BIT  technique  chosen. 

If  the  autoplace  option  is  chosen,  placebit  will  provide  an  updated  current  view  data 
base,  which  the  user  may  save  to  permanent  storage.  To  make  the  graph  “pretty,”  the 
user  is  directed  to  use  EDIGRAF,  the  graph  editor. 

Error  Message /Action. 


Message 

Action 

Node  %s  had  Tag_name  and 

No  action  required 

Tsp_ag_name  set. 

Tag_name  cleared 

TPO  count  may  be  exaggerated  due  to  fanout 

No  action  required 

Fatal  template  load  error 

Get  a  template  file 

Size  of  sets  not  equal 

Add  more  port  choices 

Two  example  output  files  follow.  The  first  is  the  “report”,  or  .rpt  output  of  the  tool. 
Information  found  here  include  the  options  chosen  in  the  run  of  the  tool,  the  nodes 
considered  (Tag_name  or  Tsp_ag_name  set),  an  itemized  list  of  the  BIT  support 
modules  to  be  added,  and  the  arcs  that  should  be  routed  to  the  modules.  The  .dwg 
information  is  more  specific  and  shows  the  steps  needed  to  reroute  all  the  graph’s  arcs 
to  gain  the  new  test  capabilities. 
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***Insert  STANDARD  HEADER  here*** 


BIT  PLACEMENT  RECOMMENDATION 

(placebit  tp_sa  wirelist) 

Test  Point  Monitoring  with  Data  Compression 

Add  pattern  generation  and  signature  analysis  on  subsystem  ‘only’,  board  ‘first’ 

The  following  nodes  will  be  considered  for  this  technique 
n9 
n2 
nl 
nO 
nlO 
n7 
n6 
nS 
n8 

Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘ag9’ 

Add  0  TPG  and  MUX2  nodes  for  internal  arcs 
Add  0  TPG  and  MUX2  nodes  for  external/PI  arcs 
Add  0  SCAN-SET  nodes 
Need  1  BILBO  and  MUX4  port  sets 

Intercept  the  following  outputs  and  route  to  the  BILBO  nodes: 
n9/Ol 
n9/02 

Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘longname’ 

Add  0  TPG  and  MUX2  nodes  for  internal  arcs 
Add  0  TPG  and  MUX2  nodes  for  external/PI  arcs 
Add  0  SCAN-SET  nodes 
Need  1  BILBO  and  MIJX4  port  sets 

Intercept  the  following  outputs  and  route  to  the  BILBO  nodes: 
nl/01 
nl/02 

Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘norm’ 

Add  1  TPG  and  MUX2  nodes  for  internal  arcs 
Add  0  TPG  and  MUX2  nodes  for  external/PI  arcs 
Add  1  SCAN-SET  nodes 
Need  0  BILBO  and  MUX4  port  sets 

Reroute  the  following  control  inputs  through  the  scan  nodes: 
nlO/Il 

Reroute  the  following  data  inputs  through  the  TPG/MUX2  nodes: 
n  10/10 

Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘al’ 

Add  1  TPG  and  MUX2  nodes  for  internal  arcs 
Add  0  TPG  and  MUX2  nodes  for  external/PI  arcs 
Add  1  SCAN-SET  nodes 
Need  0  BILBO  and  MUX4  port  sets 

Reroute  the  following  control  inputs  through  the  scan  nodes: 
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n8/Il 

Reroute  the  following  data  inputs  through  the  TPG/MUX2  nodes: 
n8/l0 

placebit  tp_sa  wirelist  completed 
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***Insert  STANDARD  HEADER  here*** 


BIT  PLACEMENT  RECOMMENDATION 
(placebit  tp_sa  wirelist) 

Test  Point  Monitoring  with  Data  Compression 

Add  pattern  generation  and  signature  analysis  on  subsystem  ‘only’,  board  ‘first’ 

Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘ag9’ 

Add  0  TPG  and  MUX2  nodes  for  internal  arcs 

Add  0  TPG  and  MUX2  nodes  for  external /PI  arcs 

Add  0  SCAN-SET  nodes 

Need  1  BILBO  and  MUX4  port  sets 

Connect  MLIX4/out(l-16)  to  BILBO/d(l-16) 

Delete  on  board  arc  from  n9/Ol 
Create  bus  to  route  through 
Add  arc  from  n9/Ol  to  new  bus 
Add  arc  from  new  bus  to  n8/I0 
Add  arc  from  new  bus  to  MUX4/Ain2 
Delete  on  board  arc  from  n9/02 
Create  bus  to  route  through 
Add  arc  from  n9/02  to  new  bus 
Add  arc  from  new  bus  to  nlO/lO 
Add  arc  from  new  bus  to  MUX4/Ain3 

Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘longname’ 

Add  0  TPG  and  MUX2  nodes  for  internal  arcs 

Add  0  TPG  and  MUX2  nodes  for  external/PI  arcs 

Add  0  SCAN-SET  nodes 

Need  1  BILBO  and  MUX4  port  sets 

Connect  MUX4/out(l-16)  to  BILBO/d(l-16) 

Delete  on  board  arc  from  nl/Ol 
Create  bus  to  route  through 
Add  arc  from  nl/Ol  to  new  bus 
Add  arc  from  new  bus  to  nlO/Il 
Add  arc  from  new  bus  to  MUX4/Ain2 
Delete  on  board  arc  from  nl/02 
Create  bus  to  route  through 
Add  arc  from  nl/02  to  new  bus 
Add  arc  from  new  bus  to  n8/Il 
Add  arc  from  new  bus  to  MUX4/Ain3 


Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘norm’ 
Add  1  TPG  and  MUX2  nodes  for  internal  arcs 


Add  0  TPG  and  MUX2  nodes  for  external/PI  arcs 
Add  1  SCAN-SET  nodes 
Need  0  BELBO  and  MUX4  port  sets 
Connect  internal  TPG/out(l-16)  to  MUX2/Ain(l-16) 
Delete  control  arc  from  nlO/Il 

Add  arc  from  nlO/Il  to  SCAN/uutinl 
Add  arc  from  SCAN/inl  to  nl/Ol 
Delete  data  arc  from  nlO/IO 

Add  arc  from  n  10/10  to  MUX2/outl 
Add  arc  from  MUX2/Binl  to  n9/02 

Add  modules  to  graph  ‘test2.hwg’  for  ambiguity  group  ‘al’ 
Add  1  TPG  and  MUX2  nodes  for  internal  arcs 
Add  0  TPG  and  MUX2  nodes  for  external/PI  arcs 
Add  1  SCAN- SET  nodes 
Need  0  BILBO  and  MUX4  port  sets 
Connect  internal  TPG/out(l-16)  to  MUX2/Ain(l-16) 
Delete  control  arc  from  n8/Il 

Add  arc  from  n8/Il  to  SCAN/uutinl 
Add  arc  from  SCAN/inl  to  nl/02 
Delete  data  arc  from  n8/I0 

Add  arc  from  n8/I0  to  MUX2/outl 
Add  arc  from  MUX2/Binl  to  n9/Ol 

placebit  tp_sa  wirelist  completed 


Additional  Information. 

See  paragraphs  describing 

a.  data  base  attributes  and  valid  syntaxes  (Paragraph  2.3.2) 

b.  results.tmp  file  (Paragraph  2.6.2.1) 

c.  output  report  header  (Figure  2-5) 

d.  BIT  techniques  (Paragraph  3.4.2) 

e.  BIT  modules  (Paragraph  3.4.3) 

BIT  modules  have  their  Tbit  attribute  set  to  “yes”,  and  their  Tboard,  Tsubsystem, 
and  Tag_name  attributes  set  appropriately.  This  helps  if  the  user  tries  to  add  a  BIT 
technique  after  one  has  already  been  Implemented.  BIT  modules  will  form  the  AG 
boundaries  and  BIT  modules  are  ignored  when  forming  AGs. 

There  is  no  difference  in  nodes  added  to  implement  odd/even  generate/check  parity. 
This  information  is  acquired  from  the  user  only  to  make  the  output  report  more  com¬ 
plete.  The  simulation  with  these  modules  will  require  accurate  manipulation  of  the 
control  lines. 

Tarc_type  is  used  to  determine  the  precedence  of  a  bus  and  associated  interconnect. 
Clock  lines  have  precedence  over  control  lines,  which,  in  turn,  have  precedence  over 
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data  lines.  If  conflicting  Tarc_types  are  connected  to  a  bus.  the  highest  available 
precedence  prevails.  This  affects  the  number  of  modules  added  in  many  techniques. 

2.7.5.  System  Summary  (compare).  Comparisons  of  .ADAS  data  bases  can  be  per¬ 
formed  with  the  System  Summary  (compare)  process.  This  feature  allows  the  user  to 
save  a  baseline  data  base  for  comparing  with  altered  versions  of  that  baseline.  This 
feature  is  most  helpful  when  various  design  for  testability  /  built-in  test  techniques 
have  been  used  and  the  incremental  hardware  overhead  costs  associated  with  the  tech¬ 
niques  are  desired. 

The  process  evaluates  the  ADAS  data  base  entries  and  attributes  to  assess  incremental 
changes  in  the  modules  and  input  and  output  parameters.  Comparisons  are  made  of 
the  number  of  modules,  primary  inputs/outputs,  test  point  outputs,  and  number  of 
BIT  modules.  Calculations  of  mean  test  time  and  mean  ambiguity  group  size  are  also 
compared. 

At  any  point  in  the  TEA  design  methodology,  compare  can  be  used.  Obviously,  it  is 
most  useful  at  the  end  of  the  design  cycle  (e.g.,  a  BIT  technique  has  been  successfully 
added  to  a  functional  representation  of  a  system  which  has  been  checked  for  unte- 
stable  constructs.),  but  the  user  can  also  use  compare  mid-cycle  to  see  incremental 
changes  in  testability  costs. 

The  user  can  gain  insight  into  the  incremental  hardware  overhead  costs  associated 
with  a  particular  step  in  the  cycle.  The  user  may  wish  to  ask  questions  such  as:  “how 
many  primary  inputs  have  I  added  to  fulfill  the  test  generation  DFT  guidelines?”  or, 
“If  I  use  this  particular  flip-flop,  will  I  save  any  overhead  (BIT)  modules?”  (Paragraph 
3.4.3). 

Another  less  obvious  use  for  compare  is  while  developing  subgraph  trees;  compare 
does  not  need  to  check  entire  hierarchy  trees;  it  can  compare  any  two  sets  of  hardware 
graphs.  If  emphasis  has  been  placed  on  a  particular  subfunction,  earlier  and  current 
views  may  be  helpful  in  determining  progress  towards  good  testability. 

The  process  compare  can  also  be  used  to  obtain  output  about  the  “current  view” 
graph  only. 

Inputs. 

The  only  input  to  compare  is  the  directory  and  filename  of  the  graph  to  be  compared 
with  the  “current  view.” 

Processing. 

The  following  paragraph  presents  the  high-level  algorithms,  special  control  features, 
and  error  handling  features  of  compare. 

/•  Ask  which  data_base  to  compare  to  the  current  view  */ 

Get(OtherDB) 

Compare(CV) 

If  OtherDB  !=  nil 

Compare(OtherDB) 

Compare(Graph) 

Open(Graph) 
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While(more  Nodes) 

Gen_AG_List(Graph,  Node,  AG_type) 
Endwhiie 

While  (more  TSUBSYSTEMs) 

Print  SUBSYSTEM  name 
While  (more  TBOARDs) 

Print  BOARD  name 

While  (more  TSP_AG_NAME) 

Print  SP_AG_NAME,  Testtime 
Print  NODE_NAME 
Endwhiie  (more  TSP_AG_NAME) 
While  (more  TAG_NAME) 

Print  AG_NAME,  Testtime 
Print  NODE_NAME 
Endwhiie  (more  TAG_NAME) 

Print  TBOARD  Stats 
Endwhiie  (more  TBOARDs) 

Print  TSUBSYSTEM  Stats 
Endwhiie.  (more  TSUBSYSTEMs) 


Processing  Notes 

The  following  calculations  were  performed  for  the  above  process: 

AG  Sizes 

a.  Mean_AG_Size  = -  ■  - 

if  AG 


Test  Times 

b.  Mean  Test  Time  = - ; — - 

-  -  #AG 


Error  Handling 

The  process  starts  and  requests  the  name  of  the  other  data  base  for  comparison  to  the 
“current  view.”  If  no  other  data  base  is  named,  the  process  is  just  run  on  the  “current 
view.”  If  the  other  named  data  base  does  not  exist,  the  user  is  warned  and  the  process 
is  exited.  If  the  other  data  base  name  is  valid,  information  is  gathered  from  each  node 
of  the  current  view  data  base  for  the  various  categories.  Two  flags  are  used  to  control 
the  program  flow  which  depend  on  the  existence  of  attributes  Tsp_ag_name  or 
Tag_name  and  Tag_test_time.  If  neither  Tag_name  nor  Tsp_ag_name  (e.g., 
node  assigned  to  group  “other”)  is  existent  for  a  given  node_name,  calculation  of  the 
mean  AG  size  and  mean  test  time  is  not  performed.  A  variable  is  incremented  each 
time  a  new  Tag_test_time  is  added  to  the  ‘Test_Time’  variable  and  each  time  a  new 
Tag_name  is  found.  An  error  occurs  if  multiple  test  times  have  been  set  for  a  single 
ambiguity  group.  After  analysis  of  each  data  base  node,  the  two  variables  representing 
the  Number_of_AGs  are  compared.  If  the  numbers  do  not  match,  a  warning  is 
reported,  indicating  that  the  test  time  value  will  not  be  accurate  due  to  a  missing 
Tag_test_time  attribute;  a  flag  indicating  this  error  is  set  for  use  during  the  report 
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generation.  The  same  procedure  is  performed  on  the  other  data  base.  .After  all  infor¬ 
mation  has  been  accumulated,  a  report  is  generated.  If  both  Tag_name  and 
Tsp_ag_name  are  set.  a  warning  is  given  and  Tsp_ag_name  is  used. 

Limitations. 

ADAS  data  base  graphs  must  already  have  been  created  before  TEA  is  entered. 

Biports  are  ignored. 

TEA  supports  the  concept  of  .ADAS  buses,  but  all  buses  are  assumed  to  be  a  single  bit 
in  widt... 

It  is  assumed  that  the  user  provides  the  ambiguity  group  test  times.  If  an  AG  does  not 
have  a  test  time  entered,  the  user  is  warned.  The  Tag_test_time  attribute  should 
only  be  entered  once  for  each  AG.  If  multiple  values  cf  a  particular  Tag_test_time 
are  given,  then  an  error  is  output. 

Test  times  are  integers.  A  test  time  value  of  ‘0’  is  interpreted  as  a  non-existent  test 
time. 

Outputs. 

At  the  completion  of  compare,  a  report  is  generated  to  illustrate  the  characteristics  of 
the  “current  view”  and  any  data  base  compared  to  it.  Included  in  this  report  are 

a.  number  of  modules 

b.  number  of  primary  inputs/outputs/test  point  outputs 

c.  mean  time  to  test 

d.  mean  ambiguity  group  size 

e.  a  table  of  names  of  modules  in  each  special  ambiguity  group 

f.  a  table  of  names  of  modules  in  each  ambiguity  group 

The  following  is  a  sample  output  report  (.rpt  file)  for  the  compare  tool.  The  “current 
view”  data  base  is  analyzed  first.  Errors  are  reported  first.  Here  there  are  no  errors; 
however,  there  could  have  been  unreported  or  inconsistent  test  times.  A  “bad”  test 
time  means  that  conflicting  test  times  were  reported  by  at  least  two  of  the  nodes  in 
the  AG.  Following  is  a  breakdown  of  each  subsystem  by  boards. 
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***Insert  STANDARD  HEADER  here*** 


SYSTEM  SUMMARY 
(compare) 

Output  report  for  graphs: 

PROJECT:[TEA.LAD.COMPARE.GRAPHSlBIGl.HWG;3  and 
PR0JECT:[TEA.LAD.C0MPARE.GRAPHSjBIG2.HWG;l 

Totals  for  graph  .  R0JECT:[TEA.LAD.C0MPARE.GRAPHS]BIGl.HWG:3 
Subsystem  ’subone’ 


Board  name 

Node 

BIT  node 

Mean  test 

PI/PO 

TPO 

Mean  AG 

count 

count 

time 

count 

count 

size 

bl 

4 

0 

3.0 

2 

0 

2.0 

b2 

3 

0 

9.5 

2 

0 

1.5 

b3 

4 

0 

4.7 

3 

0 

1.3 

Total 

11 

0 

17.2 

Totals  for  graph  PROJECT:[TEA.LAD.COMPARE.GRAPHS]BIG2.HWG;l 

Subsystem  ’subone’ 
Board  name 

Node 

BIT  node 

Mean  test 

PI/PO 

TPO 

Mean  AG 

count 

count 

time 

count 

count 

size 

bl 

2 

0 

3.0 

2 

0 

2.0 

b2 

3 

0 

9.5 

2 

0 

1.5 

b3 

4 

0 

4.7 

3 

0 

1.3 

Total 

90 

17.2 

compare  completed 

TPOs  are  arcs  with  Tdft_io  =  tpo,  test_point_output,  test_pt_output.  A  PI/PO  is 
an  arc  with  Tdft_io  labeled  as  pi,  primary_input,  po,  primary_ouiput.  BIT  nodes  are 
nodes  with  Tbit  =  bit,  bit_dt,  bit_ps,  mn,  m_n,  maintenance,  y,  yes. 

The  following  is  a  sample  output  diagram  file  (.dwg  file)  for  the  same  test  graph.  The 
“wirelist”  will  show  all  nodes  that  comprise  each  ambiguity  group  of  the  system  and 
then  each  interconnection  between  boards  is  itemized.  This  information  can  be  used 
to  help  debug  a  graph  if  inconsistent  or  unexpected  results  are  noted. 


2-79 


***Insert  STANDARD  HEADER  here*** 


SYSTEM  SUMMARY 

(compare) 

Output  wirelist  for  graphs: 

PR0JECT:[TEA.DAD.C0MPARE.GRAPHS)BIG1.HVVG:3  and 
PROJECT;[TEA.LAD.COMPARE.GR.\PHS]BlG2.HWG;l 

Structure  for  graph  PRO  JECT:[TEA.LAD. COMP  ARE. GRAPHS|BIGl.H\VG;3 

Subsystem  subone 
Board  bl 
AG  Other-ag 
Node  nlO 
Node  nOO 
AG  agl 
Node  nl 
Node  nO 
Board  b2 
AG  ag2 
Node  n4 
Node  n3 
AG  ag3 
Node  n6 
Board  b3 
AG  ag4 
Node  n9 
AG  ag5 
Node  n7 
AG  ag6 
Node  n2 
Node  n5 

List  of  connections  for  graph  PROJECT:[TEA.LAD.COMPARE.GR.\PHSlBIGl.HWG;3 

Connections  on  subsystem  ’subone’ 

Connections  on  board  ’bl’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n3/I0’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n7/I0’ 

Connections  on  board  ’b2’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n3/10’ 

Found  a  boardedge  connection  from  ’n6/O0’  to  ’n7/Il’ 

Connections  on  board  ’b3’ 

Found  an  explicit  PI/PO  connection  from  'nl/OV  to  ’n9/Il’ 

Found  an  explicit  Pl/PO  connection  from  ’n7/Ol’  to  ’n2/l0’ 

Found  an  explicit  PI/PO  connection  from  ’n7/Ol’  to  ’n5/I0’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n7/10’ 

Found  a  boardedge  connection  from  ’n6/O0’  to  ’n7/ir 


Structure  for  graph  PROJECT:[TEA.LAD.COMPARE.GRAPHSjBIG2.H\VG:l 
Subsystem  subone 
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Board  bl 

AG  agl 

Node 

nl 

Node 

nO 

Board  b2 

AG  ag2 

Node 

n4 

Node 

n3 

AG  ag3 

Node 

n6 

Board  b3 

AG  ag4 

Node 

n9 

AG  ag5 

Node 

n7 

AG  ag6 

Node 

n2 

Node 

n5 

List  of  connections  for  graph  PRO.JECT;[TEA.LAD.COMPARE.GRAPHSlBIG2.HWG;l 

Connections  on  subsystem  ’subone’ 

Connections  on  board  ’bl’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n3/I0’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n7/I0’ 

Connections  on  board  ’b2’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n3/l0’ 

Found  a  boardedge  connection  from  ’n6/O0’  to  ’n7/ir 
Connections  on  board  ’b3’ 

Found  an  explicit  PI/PO  connection  from  ’n7/Ol’  to  ’nO/Il’ 

Found  an  explicit  PI/PO  connection  from  ’n7/Ol’  to  ’n2/I0’ 

Found  an  explicit  PI/PO  connection  from  ’n7/Ol’  to  ’n5/l0’ 

Found  a  boardedge  connection  from  ’nl/OO’  to  ’n7/I0’ 

Found  a  boardedge  connection  from  ’n6/O0’  to  ’n7/Il’ 

compare  completed 


Error  Mess  age /Action. 


Message 

Action 

Node  %s  had  Tag_name  and 
Tsp_ag_name  set, 
Tag_name  cleared 

No  action  required 

One  or  more  of  the  AG  test 
times  has  not  been  set 

Set  test  times 

Multiple  times  have  been  set 
for  ambiguity  group  name 

Check  test  times 
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Additional  Information. 

See  paragraphs  describing 

a.  data  base  attributes  and  valid  syntaxes  (Paragraph  2.3.2) 

b.  results.tmp  file  (Paragraph  2.6.2. 1) 

c.  output  report  header  (Figure  2-5) 
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3.  DESIGN  FOR  TESTABILITY 


3.1.  Historical  Background. 

Ever  since  the  Invention  of  the  integrated  circuit  in  the  early  lOfiO’s.  the  rush  has  been 
on  to  place  as  many  devices  as  possible  onto  a  single  chip.  With  the  movement  into 
VLSI,  the  ability  to  test  and  verify  the  functionality  and  performance  of  electronic 
components  and  chips  has  become  extremely  difficult. 

Similarly,  the  rising  complexity  of  modern  electronic  systems  has  heightened  the  diffi¬ 
culty  of  testing  and  maintaining  these  systems.  It  is  now  generally  regarded  that  the 
cost  of  system  maintainability  is  a  major  component  of  the  overall  life  cycle  cost.  For 
this  reason,  much  effort  has  been  focused  on  reducing  the  costs  associated  with  system 
testing  and  fault  isolation.  VVfithout  the  results  of  some  of  these  efforts,  the  total  life 
cycle  costs  of  many  new  and  complex  weapon  systems  might  be  too  large  to  warrant 
their  development. 

One  of  the  approaches  used  to  reduce  testing  costs  is  to  recognize  testing  difficulties 
when  designing  the  system,  subsystem,  board,  or  chip  and  to  incorporate  certain 
features  in  the  design  to  help  these  matters.  In  other  words,  we  must  include  the  testa¬ 
bility  as  a  design  parameter  at  all  levels  of  the  design  hierarchy.  This  procedure  has 
come  to  be  known  as  design  for  testability  (DFT)  where  testability  is  defined  as  a 
design  characteristic  which  allows  the  status  (operable,  inoperable,  or  degraded)  of  a 
unit  and  the  location  of  the  faults  within  the  unit  to  be  confidently  determined  in  a 
timeh  fashion  [l]. 

Unfo.’tunately  in  the  past,  the  testing  issue  is  usually  not  addressed  until  after  the 
design  has  been  nearly  completed.  By  this  time,  the  designer  is  reluctant  to  make  even 
the  slightest  change  as  he  has  spent  considerable  effort  to  ensure  that  it  has  already 
met  the  functional  and  performance  specifications.  Management  is  likely  to  veto  any 
major  changes  for  testability  due  to  the  added  design  costs  that  will  occur. 

For  this  reason,  it  is  necessary  that  a  systematic  testability  methodology  be  included 
throughout  the  design  process  at  all  levels  of  the  design  hierarchy.  Such  a  structured 
design  for  testability  methodology  was  recently  developed  at  Research  Triangle  Insti¬ 
tute  [2]  and  enables  the  designer  to  formulate  a  design  that  is  testable  by  construction. 
This  in  turn  has  a  large  impact  on  the  total  life  cycle  costs  of  an  electronic  system. 

The  incorporation  of  design  for  testability  methods  in  electronics  first  became  practical 
with  the  onset  of  LSI  logic  in  the  1970’s.  With  the  subsequent  push  into  VLSI  and  the 
resulting  decrease  in  hardware  costs,  the  importance  and  impact  of  DFT  methods  on 
the  overall  life  cycle  costs  became  significant.  With  the  rapid  rise  in  complexity  of 
modern  weapon  systems,  it  is  not  surprising  that  the  military  services  were  early  advo¬ 
cates  of  incorporating  DFT  guidelines  into  these  systems.  The  Navy,  Air  Force,  and 
Army  have  devoted  much  effort  in  recent  years  to  this  task  under  the  coordinating 
efforts  of  the  .loint  Logistics  Commanders  Panel  on  Automatic  Testing.  The  Air  Force 
has  es[)ecially  been  active  in  this  arena  since  the  creation  of  the  Rome  .Mr  Develop¬ 
ment  Center  (R.ADC)  Testability  Program  in  1977.  Since  its  inception.  R.\DC  h:is  l^een 
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working  to  create  an  organized  testability  engineering  discipline  to  address  the  inclu¬ 
sion  of  testability  guidelines  in  the  design  procedure  [3]. 

Though  the  military  has  devoted  much  effort  to  DFT.  there  was  no  integrated  pro¬ 
cedure  for  incorporating  testability  requirements  in  military  programs  until  recently. 
This  has  been  remedied  by  the  issuance  of  MIL-STD-2165  in  1985  by  the  Na'vy  Test 
and  Monitoring  Systems  and  the  .Joint  Logistics  Commander  Panel  on  Automatic  Test¬ 
ing  [4].  This  standard,  along  with  other  guidelines  and  standards,  will  define  and  coor¬ 
dinate  the  inclusion  of  testability  requirements  in  electronic  systems  of  the  future. 

In  dealing  with  the  testability  of  a  design,  there  are  two  key  underlying  concepts,  con¬ 
trollability  and  observability,  that  are  often  used.  Controllability  is  defined  as  a  rela¬ 
tive  measure  of  how  easily  a  node  or  point  can  be  forced  to  a  specific  logic  value  by 
setting  the  inputs.  Likewise,  observability  is  a  measure  of  how  easily  the  logical  value 
of  a  node  can  be  propagated  through  the  unit  to  a  primary  output  where  it  can  be 
noted.  Many  of  the  common  DFT  techniques  are  used  to  enhance  the  controllability 
and  observability  of  certain  parts  of  a  design  to  ease  the  testing  problem. 

Design  for  testability  methods  can  generally  be  classified  into  three  groups:  ad  hoc 
guidelines,  structured  methods,  and  built-in  test  techniques.  .A.d  hoc  guidelines  are  not 
formal  or  structured  approaches,  but  are  instead  a  set  of  general  rules  and  guidelines 
that  have  been  followed  in  the  past.  These  “common  sense”  methods  include  partition¬ 
ing,  bus-oriented  design,  reset  capabilities  for  sequential  elements,  and  test  points  to 
improve  the  controllability  and  observability  of  hard-to-test  logic  blocks.  On  the  other 
hand,  structured  methods  are  a  group  of  methodical  design  rules  which  can  be  imple¬ 
mented  to  improve  testability.  These  techniques  are  mostly  variations  of  the  scan  path 
method  where  all  sequential  memory  elements  are  linked  together  into  a  long  shift 
register.  By  serially  shifting  in  test  data,  the  internal  memory  elements  can  be  con¬ 
trolled  to  ease  the  testing  problem.  Finally,  built-in  test  (BIT)  methods  take  advan¬ 
tage  of  redundant  and/or  on-board  test  circuits  to  monitor  the  operation  of  the  net¬ 
work.  When  an  error  is  detected,  the  test  circuit  sets  an  error  flag  or  no-go  signal. 

The  slow  acceptance  of  DFT  methods  in  modern  electronic  systems  can  be  partly  attri¬ 
buted  to  the  notion  that  testing  and  testability  are  a  reliability  and  maintainability 
function  and  not  a  part  of  the  design  process  [5].  .As  mentioned  earlier,  testing  con¬ 
siderations  were  not  usually  considered  until  after  the  design  was  almost  finished.  By 
this  lime,  it  was  too  late  to  incorporate  most  DFT  methods  without  incurring  large 
additional  design  costs.  This  is  because  DFT  methods  also  consume  area,  power,  and 
slightly  degrade  the  performance  of  a  design.  The  costs  associated  with  a  redesign  at 
this  point  that  still  met  all  the  performance  criteria  were  unjustifiable.  This  relegated 
few  options  to  the  test  engineer  to  improve  the  testability  of  the  network. 

For  this  reason,  it  is  Imperative  that  DFT  methods  be  included  in  the  design  process 
from  the  beginning  when  changes  can  be  made  with  minimal  cost.  While  it  is  true 
that  the  incorporation  of  a  structured  DFT  methodology  will  incur  additional  design 
effort  and  hence  costs,  one  must  remember  that  in  the  long  run  design  costs  are  only  a 
portion  of  the  overall  life  cycle  costs  of  an  electronic  component  or  system. 
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It  has  been  stated  that  the  “primary  benefit  of  testability  is  the  positive  impact  it  has 
on  system  maintenance”  [6].  This  is  due  to  the  reduction  in  test  time  necessary  to  iso¬ 
late  a  fault  to  a  specific  ambiguity  group.  Since  faulty  components  can  be  readily  iden¬ 
tified  and  replaced  in  less  time,  the  availability  of  the  system  is  increased.  In  addition, 
fault  tolerant  methods  that  make  use  of  hardware  redundancy  can  improve  system 
reliability  as  well  as  availability. 

The  impact  of  testability  can  also  reduce  costs  in  the  manufacturing  phase.  By  improv¬ 
ing  the  fault  detection  capabilities,  faulty  chips  and  components  can  be  identified  in 
less  time  before  they  are  incorporated  in  a  board  or  system.  This  also  tends  to  have  a 
favorable  impact  on  system  reliability,  maintainability,  and  availability. 

Future  efforts  in  DFT  technology  must  be  devoted  to  developing  and  refining  a  sys¬ 
tematic  testability  methodology,  enforcement  of  testability  requirements  in  all  levels  of 
the  design  hierarchy,  and  the  development  of  tools  to  assist  the  design  engineer.  The 
Test  Engineer’s  Assistant  (TEA)  is  just  such  a  tool  that  is  designed  to  assess  the  costs, 
benefits,  and  drawbacks  of  a  given  DFT/BIT  technique  in  conjunction  with  a  design. 
Through  these  efforts,  it  will  be  possible  to  integrate  the  testability  discipline  fully  into 
the  design  process. 
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3.2.1.  Gl  Guidelines  -  Aid  to  Test  Pattern  Generation.  Gl  guidelines  are  established 
to  aid  the  generation  of  test  patterns. 

Items  listed  in  the  Syntax  section  of  each  guideline  refer  to  attribute  values. 

Gl-01 

Gl-01  Guideline:  Use  flip-flops,  counters,  and  shift  registers  with  a  Preset/Clear 
capability. 

Why? 

Initialization  is  a  necessary  precursor  to  any  practical  test  and/or  simulation  pro¬ 
gram.  Ability  to  initialize  a  circuit  minimizes  the  states  the  circuit  has  to  go  through 
to  reach  a  known  state  which  is  used  as  a  basis  for  developing  tests.  Failure  to  provide 
for  circuit  initialization  control,  may  result  in  long  test  times  with  a  large  number  of 
test  vectors. 

How? 

Select  off-the-shelf  components  with  Preset/Clear  capability. 

Syntax 

inportjd:  preset,  pre,  clear,  clr 

Tnode_type:  counter,  ctr,  ff,  flip_flop,  flipflop,  reg,  register,  shift_register,  shiftregister, 
sr 

Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnode_type  is  (FF  or  CTR  or  SR)) 

While  (more  inport_ids) 

Get(next  inport_id) 

If  (inportjd  is  (PRE  or  CLR)) 
set  FOUNDONE 

Endwhile 

If  (NOT  FOUNDONE) 

report  Gl_01  Recommendation 

Endif 

Endif 

Endwhile. 
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Gl-02 

Gl-02  Guideline:  Make  Preset/Clear  a  primary  input  or  primary  input  controll¬ 
able. 

Why? 

Because  this  provides  direct  control  of  the  initialization  function  to  the  tester  and 
can  be  used  to  initialize  several  circuits  at  once  with  a  single  pulse  during  test. 

How? 

(a)  Avoid  this.  Although  the  tester  can  access  node  A  (primary  input)  to  initialize 
this  component,  the  outcome  will  be  indeterminate  when  the  tester  releases  A. 


Figure  3-1.  Gl-02  Guideline  Explanation:  Avoid  this  Configuration 

(b)  Do  one  of  these. 

(i)  The  tester  accesses  this  input  directly  or  through  other  controlling  circuitry. 

(ii)  The  tester  accesses  the  primary  input  and  clears  the  circuit  with  override. 

(iii)  The  circuit  clears  with  the  tester  override  and  also  on  power-up. 
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0), 


Primary  input  or  controlled 
from  a  primary  input 


Figure  3-2.  Gl-02  Guideline  Explanation:  Do  One  of  These 


Syntax 

inport_id:  preset,  pre,  clear,  clr 

Tarc_type:  elk,  clk_gen,  clock,  clock_generator 

Tnode_type:  flip_flop,  flipflop,  ff,  counter,  ctr,  shift_register,  sr.  shiftregister,  reg, 
register 

Notes 

All  inports  labeled  preset  or  clear  are  checked  for  primary  input  controllability. 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 
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While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnode_type  is  (FF  or  CTR  or  SR)) 

While  (more  inport_ids) 

Get(next  inport_id) 

If  (inportjd  is  (PRE  or  CLR)) 

If  (inportjd  is  NOT(PIC)) 
Report  Gl_02  Recommendation 

Endwhile 

Endwhile. 
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Gl-OS 


Gl-03  Guideline:  Make  Dselect  of  multiplexors  a  primary  input  or  primary  input 
controllable. 

Why? 

It  improves  circuit  controllability  and,  indirectly,  initialization  and  therefore  can 
result  in  reduced  number  of  test  patterns  and  reduced  test  times. 

How? 

Select  off-the-shelf  components  or: 


MUX 

SELECT 

Normal  Signal 
Control 

Primary  input  or  accessible  to  tester 
through  other  controllable  logic. 

Figure  3-3.  Gl-03  Guideline  Explanation 


Syntax 

inport_id:  dselect,  dsel,  strobe 

Tnode_type:  multiplexer,  multiplexor,  mux,  multiplex,  scan,  scannable,  y,  yes 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 

While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  Is  on  user  selected  Tsubsystem)  AND 
(node_name  Is  on  user  selected  Tboard)) 

If  (Tnode_type  Is  (MULTIPLEXER)) 

While  (more  Inport_ids) 

Get(next  Inport_Id) 

If  (Inportjd  Is  (DESELECT)) 

If  (inportjd  Is  NOT(PIC)) 

Report  Gi_03  Recommendation 

Endwhile 

If  (no  DESELECT  found) 

Report  Gl_03  Error 

End  while. 
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Gl-04 

Gl-04  Guideline:  Make  Tristate  Control  a  primary  input  or  primary  input  con¬ 
trollable. 


Why? 

It  improves  circuit  controllability  and,  indirectly,  initialization  and  therefore  can 
result  in  reduced  number  of  test  patterns  and  reduced  test  times. 

How? 

Select  off-the-shelf  components. 

Syntax 

inport_id:  trictrl,  tctrl 
Ttri_state:  tristate,  tri,  yes,  y 

Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Ttri_state  is  (TRISTATE)) 

While  (more  inport_ids) 

Get  (next  inport_id) 

If  (inportjd  is  (TRISTATE_CONTROL)) 
If  (inportjd  is  NOT(PIC)) 

Report  Gl_04  Recommendation 

Endwhile 


Endwhile. 


If  (no  TRISTATE_CONTROL  found) 
Report  Gl_04  Error 
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Gl-05 


Gl-05  Guideline:  Make  Enable/Hold  of  microprocessors  a  primary  input  or  pri¬ 
mary  input  controllable. 

Why? 

It  improves  circuit  controllability  and,  indirectly,  initialization  and  therefore  can 
result  in  reduced  number  of  test  patterns  and  reduced  test  times. 

How? 

Select  off-the-shelf  components. 

Syntax 

inport_id:  enable,  hold 

Tnode_type:  microprocessor,  up,  uproc,  u_proc 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node  name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnode_type  is  (uPROCESSOR)) 

While  (more  inport_ids) 

Get(next  inport_id) 

If  (inport_id  is  (ENABLE  or  HOLD)) 
If  (inportjd  is  NOT(PIC)) 
Report  Gl_05  Recommendation 

Endwhile 

If  (no  ENABLE  or  HOLD  found) 

Report  Gl_05  Error 

Endwhile. 
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Gl-06 


Gl-06  Guideline:  Make  Chip  Select  (CS),  Address  Latch  Enable  (ALE),  Read,  and 
Write  of  memories  primary  inputs  or  primary  input  controllable. 

Why? 

It  improves  circuit  controllability  and,  indirectly,  initialization  and  therefore  can 
result  in  reduced  number  of  test  patterns  and  reduced  test  times. 

How? 

Select  off-the-shelf  components. 

Syntax 

inport_id:  cs,  chip_sel,  chipjselect,  address_latch_enable,  add_latch_en,  ale,  write,  wr, 
read,  rd,  read_write,  readwrite,  rw 

Tnode_type:  memory,  mem,  dram,  sram,  ram,  prom,  fifo,  rom 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node_name) 

If  ((node_naine  is  on  user  selected  Tsubsystem)  AND 
(node_naine  is  on  user  selected  Tboard)) 

If  (Tnode  type  is  (DRAM  or  SRAM  or  RAM  or  ROM  or  PROM  or  FIFO)) 
While  (more  lnport_ids) 

Get(next  inport_id) 

If  (inport_id  is  (CS  or  ALE  or  RW  or  RD)) 

If  (inport_id  is  NOT(PIC)) 

Report  Gl_06  Recommendation 
Else  if  (Tnode_type  is  (ROM)) 

Report  G  1_06  Error 
Else  if  (inport_id  is  (WR)) 

If  (inportjd  is  NOT(PIC)) 

Report  Gl_08  Recommendation 

Else 


Endwhile. 


Report  Gl_06  Error 

End-while 
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Gl-01 


Gl-07  Guideline:  Make  Control  Access  of  any  bus  structure  a  primary  input  or 
primary  input  controllable. 

Why? 

It  improves  circuit  controllability  and,  indirectly,  initialization  and  therefore  can 
result  in  reduced  number  of  test  patterns  and  reduced  test  times. 

How? 

Select  off-the-shelf  components. 

Syntax 

inport_id:  control,  cntrl,  Ctrl,  bus_control,  bus_ctrl,  bus,  busnode,  bus_node 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnodejype  is  (BUS_CONTROL)) 

While  (more  inport_ids) 

Get(next  inport_id) 

If  (inportjd  is  (BUS_CONTROL)) 

If  (inportjd  is  NOT(PIC)) 
Report  Gl_07  Recommendation 

Endwhile 

Endwhile. 
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Gl-08 

Gl-08  Guideline:  Make  buried  (i.e..  not  primary  input  or  primary  input  controll¬ 
able)  control  lines  of  the  types  Preset/Clear:  Dselect  of  multiplexors:  Tristate  Control: 
Enable/Hold  of  microprocessors;  chip  select  (CS),  address  latch  enable  i.ALE).  Read, 
and  Write  of  memories:  and  Control  Access  of  bus  structures  primary  outputs. 

Wliy? 

Because  it  increases  the  observability  of  the  circuit  control  and  subsequently  the 
fault  isolation  capability  of  the  test.  This  is  particularly  true  if  a  control  signal  is  dis¬ 
tributed  to  more  than  one  ambiguity  group.  In  such  a  case,  a  buried  control  line  must 
become  observable  at  a  primary  output. 

How? 

Bring  the  control  line  in  question  to  an  unused  pin  to  the  board  I/O. 

Syntax 

Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

While  (more  inport_ids) 

Get(next  inport_id) 

If  (Tarc_type  is  (CONTROL)) 

If  (inportjd  is  NOT(PIC)) 

Report  Gl_08  Recommendation 

Endwhile 

Endwhile. 
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Gl-09 


Gl-09  Guideline:  Make  the  output  of  all  logic  redundant  nodes  a  primary  output. 
Why? 

Because  errors  on  redundant  nodes  are,  in  general,  undetectable.  An  error  on  a 
redundant  node  can  cause  an  otherwise  detectable  error  to  be  undetectable.  There¬ 
fore,  there  is  a  need  to  be  able  to  generate  tests  for  errors  on  redundant  nodes. 


How? 

Make  redundant  nodes  primary  outputs  or  use  one  of  the  scan  BIT  modules  that 
can  serialize  a  parallel  path  and  thus,  provide  observability  of  a  wide  path  through  a 
single  pin. 

Notes 

Two  recommendations  are  available. 

Certain  conditions  must  be  met  to  identify  logic  redundant  nodes.  Logic  redun¬ 
dant  nodes  have  identical  Tnode_types  (non-blank)  and  have  the  same  list  of  prede¬ 
cessors.  A  “strong”  warning  is  issued  if  the  Tnode_spec_types  match  (non-blank) 
and  the  ordering  of  inputs  is  maintained,  otherwise  a  “weak”  warning  is  issued. 

Processing 

The  following  paragraph  presents  the  guideline  procedure. 


while  (more  nodes) 

If  (node  Is  fanout) 

Find  the  children  of  the  fanout  node 
Find  the  list  of  parents  for  each  child 
Sort  the  list  of  parents  for  each  child 
Alphabetize  list 
Remove  duplicates 

For  each  of  the  children  with  Identical  sorted  parent  lists 
If  Tnode_spec_ty  pe  of  children  do  not  match 

Report  Gl_00_weak  Recommendation 

Else 

If  unsorted  parent  list  match 

Report  Gl_Ofl_strong  Recommendation 

Else 

No  warning 

If  (node  not  OO) 

Report  G1_00  Recommendation 


Endfor 

Endwhile. 
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Gl-10 


Gl-10  Guideline:  Make  the  trunk  section  of  high  fanout  nodes  or  junctions  a  pri¬ 
mary  output. 

The  threshold  for  this  guideline  is  stored  in  the  system  test  requirements;  the  default 
value  is  5. 

Why? 

To  increase  the  observability  of  the  fanout  node.  An  error  on  this  node  will 
decrease  the  fault  isolation  capability  of  a  test. 

How? 

Make  this  node  a  primary  output. 

NOTE:  Use  this  guideline  if  you  don’t  use  guideline  G2-02. 

Syntax 

Tnode_type:  fanout,  copy,  null 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  nodes) 

Get(next  node) 

If  ((name  is  on  user  selected  Tsubsystem)  AND 
(name  is  on  user  selected  Tboard)) 

If  (large  fanout  device) 

If  (device  is  NOT  OO) 

Report  Gl_10  Recommendation 

Endwhile. 
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Gl-11 


Gl-11  Guideline:  Terminate  all  unused  device  inputs  and  tristatable  outputs. 


Why? 

From  a  design  point  of  view,  unused  inputs  to  logic  devices  should  always  be  Ter¬ 
minated  to  VDD  or  Ground  through  a  suitable  resistor  to  remove  the  risk  of  noise  that 
can  be  picked  up  by  floating  Inputs. 

From  a  testing  point  of  view,  termination  through  a  proper  resistor  may  allow 
control  of  the  device’s  unused  inputs  by  the  tester.  Termination  of  tri-state  devicp 
outputs  through  a  pull-up  resistor  can  prevent  inconsistent  logic  values  leading  to 
inconsistent  node  signatures. 

How? 

Use  an  appropriate  resistor  connected  to  the  appropriate  logic  level. 


Unused  Input 


Figure  3-4.  Gl-11  Guideline  Explanation 
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Syntax 

Ttri_state:  tristate,  tri,  yes,  y 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 

While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

While  (more  inport_ids) 

Get(next  inport_id) 

If  (inport_id  has  no  source) 

Report  Gl_ll  Recommendation 

Endwhile 

If  (Ttri_state  is  (TRI_STATE) 

While  (more  outport_ids) 

Get(next  outport_id) 

If  (outport_id  has  no  sink) 

Report  Gl_ll  Recommendation 

Endwhile 

Endwhile. 
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Gl-12 


Gl-i2  Guideline:  Keep  analog  and  digital  circuits  physically  apart. 

WTiy? 

For  two  reasons: 

(a)  To  avoid  crosstalk  problems  in  digital  lines  which  run  close  to  analog  lines 

(b)  The  testing  requirements  and  strategies  for  analog  circuits  are  substantially 
different  from  those  for  digital  circuits  and  therefore  it  is  preferable  to  test  them 
separately. 

How? 

Use  physical  separation  when  it  is  necessary  to  mix  digital  and  analog  on  the  same 
board.  Use  separate  boards  if  possible.  If  digital  signals  have  to  be  routed  close  to 
analog  lines,  then  the  digital  lines  should  be  properly  balanced  and  shielded  transmis¬ 
sion  lines. 

Syntax 

Tdevice_type:  a,  analog,  d,  digital,  mix 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tdev  type  is  (ANALOG)) 

Append  to  anaIog_list 

Else 

Append  to  digitaMist 

Endwhile 

If  (analogjist  AND  digitaljist  NOT(EMPTY)) 

Report  Gl_12  Recommendation 

End. 
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Gl-13 

Gl-13  Guideline:  Make  analog  lines  used  as  input  to  digital  data  acquisition  cir¬ 
cuits  a  primary  output. 

Why? 

Because  in  this  way  the  analog  and  digital  sections  of  these  circuits  can  be  tested 
separately  and  with  different  test  equipment,  if  necessary. 

How? 

For  the  case  of  an  analog  signal,  make  its  line  a  primary  output.  In  the  case  of 
digital  inputs  to  a  D/A,  either  make  them  primary  outputs  or  use  a  scan-set  module  to 
sample  the  signal  in  parallel  and  shift  it  out  serially  thus  minimizing  pin  overhead. 

Syntax 

Ta_d:  a,  analog,  d,  digital 
Tdevice_type:  a,  analog,  d,  digital,  mix 
Tnode_type:  da,  data_acquisition,  mix 

Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  nocle_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnode_type  is  (DIGITAL_DA)) 

While  (more  inport_ids) 

Get(next  inport_id) 

If  (Ta_d  is  (ANALOG)) 

If  (outport_id  is  NOT  OO) 
Report  Gl_13  Recommendation 

Endwhile 


Endwhile. 
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Gl-U 

Gl-i4  Guideline:  Avoid  asynchronous  logic. 


Why? 

.\lthough  the  performance  benefits  can  lie  significant  by  using  asynchronous  logic, 
the  testing  problems  can  also  be  significant.  This  is  due  primarily  to  the  possibility  of 
races  introducing  non-deterministic  behavior.  Providing  test  patterns  for  such  circui¬ 
try  can  be  very  difficult. 

How? 

Use  synchronous  counters  rather  than  asynchronous  ripple  counters  or  even 
asynchronously-coupled  synchronous  counters,  .\void  self-timed  logic  as  much  as  pos¬ 
sible  and  tie  everything  to  the  clock  or  its  derivatives  as  much  as  possible. 

Syntax 

inport_id:  clock,  elk 

Tarc_type:  clock,  elk,  elock_generator,  clk_gen 
Tasynch:  async,  asynch,  asynchronous,  y,  yes 
Tdevice_type:  a,  analog,  d,  digital 
Tlogic_type:  combinational,  combjogic,  comb 
Tnode_type;  clock,  elk,  clock_generator,  clk_gen 

Note 

If  the  user  does  not  eliminate  an  asynchronous  construction  and  wants  it  identi¬ 
fied  by  the  other  tools,  the  user  should  set  the  Tasynch  attribute  on  the  identified 
nodes. 

Also,  this  guideline  is  not  intended  to  identify  intentionally  used  asynchronous 
logic;  therefore,  nodes  with  Tasynch  set  affirmatively  will  not  be  flagged. 

Processing 

The  following  paragraph  presents  the  guideline  procedure. 
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While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)  AND 
(NOT  VISITED)) 
node  is  VISITED 
While  (more  inport_ids) 

Get(next  inport_id) 

If  (inportjd  is  (CLOCK)) 

If  (inport_id  source  is  (COMB_LOGIC)) 
Get(source  node) 

While  (more  inport_ids) 

Get  (next  inport_id) 

If  (inport_id  is  ancestor  of  clock) 
Report  Gl_14  Recommendationl 
Else 

Report  Gl_14  Recommendation2 
Endwhile 

Endwhile 

Endwhile. 
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Gl-15 

Gl-15  Guideline:  Avoid  uncontrollable  feedback. 

Why? 

Uncontrollable  feedback  paths  complicate  both  test  generation  and  fault  diagnosis 
(isolation).  In  some  circuits,  establishing  a  known  state  may  be  difficult  in  presence  of 
uncontrollable  feedback  paths. 


How? 


Logic 


<3 


WTDD 


Tester  Control 


or 


Patterns 

Figure  3-5.  Gl-15  Guideline  Explanation 


Hints. 

a.  If  all  nodes  in  a  loop  are  combinational,  an  error  condition  exists. 

b.  If  Tlogic_type  is  blank,  it  is  assumed  that  the  node  is  sequential. 

c.  If  a  loop  is  self-contained  on  a  single  board  without  any  primary 
inputs/outputs,  an  error  condition  exists. 
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d.  A  node  with  no  inports  is  considered  primary  input  controllable. 

e.  Don’t  set  the  Tboard  and  Tsubsystem  attributes  on  a  fanout  node. 

f.  All  controllable  loops  must  have  one  primary  input  controllable  arc. 

g.  Small  loops  that  are  part  of  bigger  loops  will  not  be  detected. 

Procedure  for  finding  loops 

while(more  nodes) 
pick  a  node 

find  all  nodes  you  can  reach  from  this  node 
if  you  can  get  back  from  the  new  node  to 
the  original  node,  it’s  part  of  a  loop 


Processing 

The  following  paragraph  presents  the  guideline  procedure. 


Find  (nodes  connected  by  data  arcs) 

Get  (node  from  loop) 

While  (more  inports) 

If  (inport  is  NOT  part  of  loop) 

If  (inport  is  NOT  PIC) 

Report  Gl_15  Recommendation 
Goto  next  loop  of  nodes 
Endwhile. 
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Gl-16 


Gl-16  Guideline:  Avoid  one-shots  as  delay  elements. 


Why? 

One-shots  drift  and  can  give  undependable  timing  pulses. 
How? 

Use  counters  or  timers  as  delay  elements. 

Syntax 

Tnode_type:  oneshot,  one_shot 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  nocle_names) 

Get  (next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnode_type  is  (ONE_SHOT)) 

Report  Gl_16  Recommendation 

Endwhile. 
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3.2.2.  G2  Guidelines  -  Aid  to  Test  Pattern  Application.  G2  guidelines  are  established 
to  aid  the  application  of  test  patterns. 

G2-01 

G2-01  Guideline:  Make  all  on-board  clocks  a  primary  input  or  primary  input  con¬ 
trollable. 

Why? 

If  a  circuit  contains  an  on-board  free-running  clock  (oscillator),  it  may  be  neces¬ 
sary  to  replace  it  with  a  tester-provided  clock  to  reduce  the  speed  of  the  circuit  (if 
necessary)  for  testing  purposes  or  to  debug  the  test  patterns. 

How? 


Board  Clock 


Figure  3-6.  G2-01  Guideline  Explanation 


Syntax 

outport_id;  clock,  elk 

Tnode_type:  clk_gen,  clock_generator,  elk,  clock 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 
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While  (more  node_names) 

Get(next  node  name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnode_type  is  (CLOCK)) 

While  (more  outport_ids) 

Get(next  outport_id) 

If  (outportjd  is  (CLOCK)) 

If  (outport  id  is  NOT(OO)) 
Report  G2_01  Recommendation 


Endwhile 


Endwhile. 
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G2-02 

G2-02  Guideline:  Avoid  fanout  greater  than  5. 

Why? 

High  fanout  lines  decrease  the  fault  isolation  capability  of  a  test  set. 
How? 


Figure  3>7.  G2-02  Guideline  Explanation 
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Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names  or  bus_names) 

Get(next  name) 

If  ((name  is  on  user  selected  Tsubsystem)  AND 
(name  is  on  user  selected  Tboard)) 

If  (fanout  device) 

While  (more  outport_ids) 

Get(next  outport_id) 

Find  children  of  fanout 
If  (#  of  children  >  5) 

Report  G2_02  Recommendation 


Endwhile 


Endwhile. 
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G2-0S 


G2-03  Guideline:  Break  up  long  counter  chains  greater  than  8  bits  with  logic  that 
contains  primary  inputs  or  primary  input  controllable  lines. 

Why? 

Because  this  results  in  reduction  of  the  number  of  test  patterns  required  to  fully 
test  the  counter. 

NOTE:  Follow  this  guideline  when  you  use  more  than  one  counter  chip  to  form  long 
counters.  Do  not  replace  a  single  chip  (long)  counter  with  several  short  counter  chips. 

How? 


(Controlled  from  PI. 
removed.) 


In  this  case  the  resistors  and  the  connection  to  VDD  can  be 


Figure  3-8.  G2-03  Guideline  Explanation 
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Syntax 

inport_id:  clock,  elk 
outport_id:  co,  carry_out,  carry 
Tnode_type:  counter,  ctr,  count 

Processing 

The  following  paragraph  presents  the  guideline  procedure. 

While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

While  (Tnode_type  is  (COUNTER)) 

Append  (nodejaame  to  CounterJList) 

Endwhile 

Cleanup  (lists) 

While  (Counter_lists) 

Clear  totaI_count_bits 

While  (more  nodes  on  Counter_List) 

Get  (Node_name  off  Counter_List) 

If  ((next  node_type  is  NOT  combinational)  AND 
(next  node  is  NOT  PIC)) 

If  (next  node  is  COUNTER) 

add  Tcount_bits  to  total_count_bits 

Endwhile 

If  (total_count_bits  >  8) 

Report  G2_03  Recommendation 

Endwhile. 
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G2-04  Guideline:  Avoid  mixed  logic  families  on  the  same  board  unless  all  I/O  is 
compatible  in  logic  levels  and  rise  and  fall  times. 

Why? 

I/O  level  capability  of  all  components  on  a  board  makes  it  feasible  for  the  tester 
to  supply  the  required  logic  levels.  It  will  be  difficult  for  the  tester  to  supply  tests  to 
components  expecting  different  logic  levels  during  the  run  of  a  single  test  set. 

How? 


4,5  ECL  parts, 
TTL  compatible 
1,2,3  ECL  parts. 
6,7  TTL  parts. 


Choose  1,2,3  to  also  be  TTL-compatible  so  the  same  test  set  can  be  applied  or 
monitored  at  the  TP  interface. 

Figure  3-9.  G2-04  Guideline  Explanation 


Syntax 

Tlogic_family:  ttl,  iil,  eel,  gaas,  emos,  nmos,  other 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


Logicjist  =  NULL 

While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

Get  (Tlogic_family  of  node_name) 

Append  (Tlogic_family  to  logic_list) 

Remove  (duplicates  from  logic_list) 

Endwhile 

If  (logic_list  >  1  Tlogic_family) 

Report  G2_04  Recommendation 
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G2-05 


G2-05  Guideline:  Limit  chip  fanout  at  test  points  to  one  less  than  the  specified 
maximum. 


Why? 

To  allow  for  the  tester  loading  when  the  tester  accesses  the  test  points. 

How? 

After  test  points  have  been  determined,  check  the  chip  fanouts  against  the  chip 
data  sheets  to  identify  violations  of  this  guidelines. 

Syntax 

Tnode_type:  fanout,  copy,  null 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_names) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node  name  is  on  user  selected  Tboard)) 

While  (more  outport_ids) 

Get(next  outport_id) 

If  (Tdft_io  is  (TPO)) 

Find  children  of  node_name 

If  (^  children  >  of  node_name_Tchip_maxfan  —  1) 
Report  G2_05  Recommendation 

Endwhile 

Endwhile. 
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G2-06 

G2-06  Guideline:  Provide  the  refresh  circuitry  for  DRAMs  on  the  same  board  as 
the  RAM. 

Why? 

If  the  DRAM  refresh  circuitry  is  not  on-board,  then  the  tester  has  to  provide  it 
and  this  can  be  a  problem  for  two  reasons: 

(a)  The  tester  may  not  be  fast  enough  to  both  provide  the  refresh  cycle  and  also 
perform  the  required  tests. 

(b)  In  terms  of  test  programs,  there  is  a  need  to  incorporate  regular  calls  to  refresh 
subroutines. 

How? 

By  design,  place  the  refresh  circuitry  on  the  memory  board. 

Syntax 

Tnode_type:  dram 
Processing 

The  following  paragraph  presents  the  guideline  procedure. 


While  (more  node_nanies) 

Get(next  node_name) 

If  ((node_name  is  on  user  selected  Tsubsystem)  AND 
(node_name  is  on  user  selected  Tboard)) 

If  (Tnode  type  is  (DRAM)) 

Report  G2_06  Recommendation 

Endwhile. 
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3.2.3.  Recommended  Order  of  .Application.  The  user  has  the  opportunity  to  run  all  or 
any  of  the  DFT  guidelines  on  each  of  the  boards  of  his  system.  If  some  resource  is  lim¬ 
ited  (e.g..  computer  time  or  budget),  RTI  system  designers  recommend  running  the  Gl 
guidelines  in  the  following  order 

a.  Gl-lo 

b.  Gl-01 

c.  Gl-14 

d.  Gl-11 

e.  Gl-02 

f.  Gl-03 

g.  Gl-04 

h.  Gl-05 

i.  Gl-07 

j.  Gl-06 

k.  Gl-08 

l.  Gl-09 

m.  Gl-10 

n.  Gl-13 

o.  Gl-12 

p.  Gl-16 

and  the  G2  guidelines  in  the  following  order 

a.  G2-01 

b.  G2-06 

c.  G2-03 

d.  G2-04 

e.  G2-05 

f.  G2-02  (only  need  if  Gl-10  not  run) 

The  above  order  of  application  only  has  significance  if  the  guidelines  are  run  one  at  a 
time.  If  multiple  guidelines  are  run  at  the  same  time,  TEA  determines  the  order  of 
application  —  Gl.  the  G2  guidelines,  starting  low  to  high. 

3.2.4.  User-defined  Guidelines.  Wlien  the  user  wants  to  add  his  own  design  for  testa¬ 
bility  guidelines  to  those  known  by  the  Design  for  Testability  Guideline  Checker  (dft  -- 
Paragraph  2.7.1),  he  must 

a.  write  prolog  code  to  implement  guideline 
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b.  write  a  report  generator  to  interface  with  the  report  access  utility  (Paragraph 

2.6.2) 

c.  either  add  documentation  about  the  guideline  to  the  TEA-supplied  VAIS  help 
library  (Paragraph  2.6.3)  or  provide  some  other  information  source  to  users 

d.  let  dft  know  about  the  existence  of  the  code  by  setting  a  \AIS  logical. 
tea_rules.  to  point  to  the  file  that  contains  the  names  of  the  user-supplied 
guidelines,  one  per  line. 

An  example  of  the  procedure  to  let  dft  know  about  the  existence  of  a  user-supplied 
guideline  follows.  The  code  that  follows  is  an  example  of  a  guideline  that  could  be 
added  to  the  guideline  data  base.  It  is  a  rewrite  of  an  existing  guideline,  so  this  exam¬ 
ple  can  be  copied  and  run,  as  is,  including  the  .com  and  .txt  files.  This  file  should  be 
called  my_rules.pl. 
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%% 

%%  Dispatch  code  for  a  selected  rule. 

%% 


%% 

%% 

%% 


%%  The  main  routine  for  DFT  analyze  calls  routines  like  the  one  below  %% 
%%  for  each  rule  selected  from  the  main  menu.  The  first  parameter  to  %% 
%%  the  dispatch  clause  Is  the  name  of  the  rule  and  the  second  Is  the  %% 
%%  file  pointer  to  the  results. tmp  file.  %% 
Vk  %% 


dft_analyze_dispatch_rule(my_rule,  Outfile) 
write(’running  my_rule’),  nl, 
write(Outrile,’*my_rule*’),  nl(Outrile), 
do_my_rule(Outfile), 

w-rlte(Outfile,’*my_rule_END*’),  nl(Outrile). 


%%  Vh 
%%  Main  body  of  rule  definition.  %% 
%%  %% 


%%  This  rule  will  find  nodes  with  a  fanout  from  a  given  port  of  %% 
%%  greater  than  1  (l.e.  any  port  that  connects  to  a  fanout  node 
%%  or  bus)  %% 

%%  %% 


do_my_rule(Outfile) 
get_valid_node(Node), 
outputs(Node,  Outputs), 

check_high_fanout(Outrile,  Node,  Outputs,  0), 


fail. 


%%  Check  each  outport  of  a  node  for  a  high  fanout  value.  % 

%%  % 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

check_hlgh_f anout (Outf lie ,  Node,  [HeadiTail],  Port_nuin) 
length (Head,  Fanout), 

Fanout  =<  1, 

New_port_nuin  Is  Port_nuin  +  1 , 

!  ^ 

check_hlgh_f anout (Outf lie ,  Node,  Tall,  New_port_num) . 

check_hlgh_f anout (Outf lie ,  Node,  [_|Tall] ,  Port_num) 
write (Outf lie ,  ‘Node  *) , 
write (Outf lie.  Node), 
write (Outf lie ,  '  port  ’), 
write (Outf lie ,  Port_num) , 

write (Outf lie,  '  has  fanout  greater  than  1*), 
nl  (Outf lie) , 

New_port_nuin  Is  Port_nuin  +  1, 

! . 

check_hlgh_f  anout  (Outf  lie.  Node,  Tall,  New_port_nuin)  . 

This  is  the  text  of  the  file  called  my_rules.txt.  This  file  will  be  used  by  the  command 
file  to  set  the  VMS  logical  tea_rules.  The  command  file  is  listed  below. 

my_rule 

This  is  the  text  of  the  file  called  my_rules.com.  This  file  is  run  by  typing 

$  @ my_rules.com 

This  file  sets  the  VMS  logical  tea_rules  to  find  the  name  of  the  new  guideline  to  be 
added  to  the  guideline  data  base.  In  this  example,  the  logical  will  point  to  the  file 
my_rules.txt,  given  above. 


$  ! 

$  !  Define  TEA_RULES  to  tell  TEA  where  to  find  the  list  of  my  rules. 

$  !  If  the  servant  is  built,  you  only  need  to  define  this  logical,  the  second 
$  !  half  of  this  file  is  for  building  the  prolog  servant  file. 

S  ! 

$  define  tea_rules  my_rules.txt 

$  ! 

$  !  Build  a  prolog  servant  file  with  my  rules  added  in  the  current  directory. 

$  !  Uses  shortcut  method  to  start  prolog  and  pass  it  commands  from  a  command 
$  !  file. 

$  ! 

$  quintus_engine  tea_prolog:dft.prolog 

[my_rules|. 

[’tea_prolog;build_servant’]. 

halt. 

$  exit 

The  user  is  directed  to  the  VMS  manual  set  for  information  about  adding  information 
to  a  help  library.  The  user  will  not  be  able  to  access  his  information  through  dft 
explain,  but  will  be  able  to  access  it  through  normal  use  of  the  On-line  User  Support 
System  (Paragraph  2.6.3). 

The  user  is  given  no  guidance  in  writing  prolog  code  with  TEA.  Refer  to  the  Quintus 
manuals. 

Appendix  D  shows  ADAS-related  information,  including  data  base  file  formats  and 
data  base  access  routines. 

Warnings  to  the  User 

a.  No  user-defined  guideline  shoulu  have  the  character  in  its  name.  There 
is  a  possibility  that  there  would  be  a  conflict  with  TEA-supplied  menu  items. 

b.  The  user  will  have  no  interface  to  the  report  generator  (Paragraph  2.6.2) 
unless  he  provides  it.  It  is  recommended  that  the  user  generate  his  own 
report,  with  a  filename  ending  with  the  extensions  .rpt,  .dwg,  or  .help  so  that 
the  report  access  utility  can  print  the  user’s  reports  to  the  screen  or  printer 
automatically  from  the  TEA  user  interface. 
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3.3.  TEA  Hierarchical  Approach  to  Design  for  Testability.  The  reader  is  directed  back 
to  Figure  2-4  for  this  discussion.  Figure  2-4  illustrates  the  TEA  concept  of  a  testable 
system.  On-board  BIT  support  modules  are  shown  communicating  to  an  on-board 
maintenance  manager  which,  in  turn,  talks  to  a  maintenance  bus  to  report  board  test 
results.  A  test  control  unit  monitors  the  subsystem  test  results  for  the  system  and 
may  also  control/communicate  with  any  automated  test  equipment  needed  to  apply 
tests. 

One  possible  scenario  involves  the  user  signaling  the  system  test  control  unit  that  it  is 
to  run  a  standard  diagnostic.  The  control  unit  sends  necessary  signals  along  the  test 
bus  to  signal  each  subsystem  to  start  its  diagnostic  procedure.  The  subsystem  test 
control  unit  then  provides  input  vectors  (from  some  storage  area)  and/or  control  sig¬ 
nals  to  each  board  to  begin  the  board  testing.  The  maintenance  node  may  issue  start 
commands  to  self-testable  chips,  feed  scan  chains  with  appropriate  input  data  and  con¬ 
trol  and  start  test  pattern  generators  for  the  rest  of  the  circuitry.  When  an  appropri¬ 
ate  amount  of  time  has  passed,  the  controller  polls  each  board  maintenance  node  for 
test  results,  which  may  include  a  faulty  ambiguity  group,  and  this  information  is 
passed  to  the  system  test  controller  for  relay  to  the  user. 

This  system  of  hierarchical  responsibility  and  reporting  supports  a  testable  design  in 
both  fault  detection  and  fault  isolation.  This  system  is  the  result  of  applying  the  TEA 
methodology  described  in  Paragraph  2. 

TEA  supplies  a  library  of  BIT  support  modules  (Paragraph  3.4.2)  to  provide  the  kind 
of  tasks  necessary  to  implement  a  board  test  strategy,  including  one  version  of  a  board 
maintenance  controller,  which  may  be  used  to  control  the  BIT  support  modules.  TEA 
recognizes  the  Element  Test  and  Maintenance  (ETM,  from  the  VHSIC  Phase  II  con¬ 
tractors)  and  Joint  Test  Action  Group  (JTAG)  bus  structures  at  the  board  level. 

The  following  figures  are  used  to  illustrate  the  standard  configurations  that  TEA 
recognizes.  TEA  always  wants  to  see  either  of 

a.  an  ETM  or  JTAG  support  module 

b.  primary  input  and  outputs 

c.  a  maintenance  node 

at  the  head  and  tail  of  these  rings  and  stars. 

Figures  3-10  and  3-11  show  the  ETM  configurations.  The  nodes  must  have  their 
Tscan  attribute  set  to  etm  or  vhsic  and  must  have  inports  and  outports  named  just 
as  they  are  in  the  figure.  Depending  on  the  particular  configuration,  ring  or  star, 
either  “DATAIN’7“DATAOUT”  are  chained  or  bused.  If  “DATAIN’7“DATAOUT” 
is  chained  (ETM  ring),  then  there  is  a  single  SELECT  line.  There  is  always  a  bused 
JMODE  line.  (Note:  “MODE”  is  a  reserved  word  in  Quintus  Prolog  so  TEA  looks  for 
“.JMODE”  instead  of  “MODE”  as  in  the  standard.) 


3-41 


Figure  3-10.  ETM  Ring  Configuration 


DATAIN 

DATAOUT 

JMODE 

SELECT(O) 


SELECT(n) 


Figure  3-11.  ETM  Star  Configuration 
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Figures  3-12  and  3-13  show  the  JTAG  configurations.  The  nodes  must  have  their 
Tscan  attribute  set  to  jtag  and  must  have  inports  and  outports  named  just  as  they 
are  in  the  figure.  Depending  on  the  particular  configuration,  ring  or  star,  either 
“SDr’/“SDO”  are  chained  or  bused.  If  “SDI”/“SDO”  is  chained  (JTAG  ring),  then 
there  is  a  single  .JMODE  line.  There  is  always  a  bused  SCK  line. 

The  user  needs  to  carefully  study  his  requirements  and  limitations  and  decide  on  sub¬ 
system  and  system  level  test  bus  protocols  and  test  control  units.  This  is  not  done  by 
TEA. 
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SCK 


Figure  3-12.  JTAG  Ring  Configuration 


MODEN 

MODEl 

MODEO 

SCK 


SDI 

SDO 


Figure  3-13.  JTAG  Star  Configuration 
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3.4.  Built-in  Test  (BIT). 


3.4.1.  Historical  Background. 

The  tremendous  increase  in  complexity  in  electronic  systems  over  the  last  decade  has 
been  paralleled  by  a  rise  in  complexity  in  Automatic  Test  Equipment  (ATE).  Even  so, 
testing  technology  has  failed  to  keep  pace  with  the  growth  of  system  technology  creat¬ 
ing  enormous  problems  for  the  test  community.  .As  a  result,  the  time  and  costs  associ¬ 
ated  with  test  generation  and  application  have  increased  significantly  over  this  period. 

.As  early  as  1959.  the  Third  Annual  Joint  Military-Industrial  Electronic  Test  Equip¬ 
ment  Symposium  stated  that  “the  need  remains  for  built-in  performance  monitoring 
devices  in  electronic  systems.  The  degree  of  omission  of  this  class  of  devices  from  prime 
equipments  constitutes  a  striking  example  of  immature  design  in  electronic  systems. 
There  is  no  “method’  of  testing  more  automatic  than  continuous  monitoring;  still  this 
technique  seems  to  have  been  ignored  in  those  types  of  systems  where  it  could  be 
employed  most  effectively.”  This  statement  was  made  three  years  before  the  invention 
of  the  integrated  circuit.  Thus,  in  today’s  world  where  thousands  of  logic  gates  can  be 
placed  on  a  single  chip,  the  need  for  built-in  test  (BIT)  is  greater  than  ever.  In  fact, 
recent  studies  have  concluded  that  the  incorporation  of  BIT  and  DFT  methods  at  all 
design  levels  has  a  positive  Impact  on  system  reliability,  maintainability,  and  supporta- 
billty. 

The  high  costs  of  testing  can  generally  be  attributed  to  the  costs  of  test  generation  and 
test  application.  It  has  been  observed  that  the  computational  time  (and  costs)  associ¬ 
ated  with  test  pattern  generation  varies  approximately  as  the  cube  of  the  number  of 
gates.  With  today’s  VLSI/VHSIC  technology,  these  costs  can  be  prohibitive  in  the 
development  of  a  system.  Likewise,  the  costs  of  applying  a  long  serial  test  sequence 
through  a  slower  external  tester  are  undesirable. 

For  these  reasons,  the  concept  of  BIT  has  been  the  subject  of  much  research  due  to  its 
potential  for  reducing  these  costs.  For  example,  random  or  pseudo-random  patterns 
can  be  generated  on-board  the  module  thereby  eliminating  the  need  for  generating  test 
vector  sets.  In  addition,  the  test  results  are  often  compressed  on-board  using  data  com¬ 
paction  methods  that  reduce  the  amount  of  storage  and  analysis  needed  to  interpret 
them.  This  use  of  built-in  test  pattern  generators  and  data  compactors  can  greatly 
reduce  the  need  for  expensive  ATE.  In  most  cases,  a  simple  external  tester  is  sufficient 
to  obtain  the  results  of  the  test  sequence. 

Built-in  test  is  most  often  used  to  reduce  the  mean  time  necessary  to  detect  and  isolate 
faults  to  a  specific  ambiguity  group  within  a  system.  In  such  a  manner,  it  can  speed 
the  replacement  of  faulty  components  and  reduce  unscheduled  maintenance  time.  This 
impacts  favorably  on  system  availability  as  well  as  maintainability.  In  the  manufactur¬ 
ing  phase,  built-in  test  can  be  used  to  verify  the  functionality  of  a  component  before 
its  incorporation  into  a  higher  level,  thus  improving  overall  system  reliability. 

However,  BIT  is  not  without  some  drawbacks.  At  all  levels  of  the  design  hierarchy,  the 
inclusion  of  BIT  modules  consumes  area  and  power.  As  a  consequence  of  this  at  the 
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chip  level,  the  expectant  yield  of  IC’s  will  be  reduced  and  the  production  costs  will 
subsequently  increase  [7j.  Nevertheless,  the  resultant  savings  in  ail  phases  of  testing 
throughout  the  system  life  cycle  warrant  the  inclusion  of  built-in  test  as  a  desirable 
feature. 

In  the  early  days,  "he  performance  of  BIT  circuits  in  detecting  and  isolating  faults  lid 
not  meet  expectations.  Numerous  false  alarms  caused  by  t  he  BIT  circuitry  significantly 
increased  the  maintenance  costs  abo\"e  expected  levels  during  the  1970's.  However, 
recent  improvements  in  testing  technology  through  advanced  processing  capabilities 
have  improved  the  rate  of  false  alarms  and  consequently,  the  number  and  costs  of  field 
service  pulls. 

The  military  services  have  been  especially  interested  in  the  capabilities  of  BIT  to 
reduce  the  maintenance  and  support  costs  for  modern  weapon  systems  in  the  field.  At 
present,  the  Army  uses  a  three-tier  maintenance  concept  which  relies  on  initial  isola¬ 
tion  of  a  fault  to  occur  at  the  unit  level.  The  faulty  module  is  replaced  and  shipped  to 
the  intermediate  level  for  additional  testing  and  isolation.  It  is  then  shipped  to  the 
depot  where  the  faulty  component(s)  are  replaced  and  placed  back  in  the  spare  parts 
inventory  line.  Recent  studies  undertaken  by  the  Army  have  concluded  that  BIT  tech¬ 
nology  has  not  yet  advanced  to  the  point  where  a  twotier  maintenance  concept  can  be 
supported.  To  promote  the  advancement  of  BIT  capabilities,  the  Army  has  recently 
formed  a  BIT/BITE  (Built-In  Test  Equipment)  Center  of  Excellence  within  the  .\rmy 
Test,  Measurement,  and  Diagnostic  Technology  Laboratory.  Their  goal  is  to  further  the 
built-in  test  capabilities  of  systems  to  provide  better  isolation  capabilities  at  the  unit 
level,  thus  eliminating  the  need  for  an  intermediate  maintenance  level  [8). 

Currently,  the  armed  forces  are  in  the  midst  of  the  MdSIC  program  to  upgrade  and 
modernize  military  electronic  systems  through  the  incorporation  of  reliable,  testable. 
"VXSI  components.  One  of  the  goals  during  the  initial  phase  of  the  VHSIC  program  was 
to  implement  BIT  techniques  that  would  assure  a  high  fault  coverage  for  chips,  boards, 
and  subsystems.  However,  independent  efforts  by  the  various  contractors  led  to  a 
variety  of  techniques  being  implemented.  Consequently,  it  was  realized  that  it  would 
be  difficult  to  construct  testable  systems  due  to  the  lack  of  a  structured  scheme  to 
coordinate  the  test  activities  [9]. 

This  problem  is  currently  being  addressed  in  Phase  II  of  the  VHSIC  program  through 
the  development  of  two  maintenance  busses.  In  addition  to  these,  the  Phase  II  contrac¬ 
tors  are  developing  a  PI-Bus  that  will  be  used  for  modifle  to  module  communications 
that  will  allow  chips  from  different  chip  sets  to  be  interconnected  easily  without  the 
need  for  additional  logic.  Figure  3-1-1  on  the  next  page  graphically  depicts  the  VHSIC 
bus  implementation. 
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TM  =  Test  and  Maintenance  Bus 
ETM  =  Element  TM  Bus 

PI  =  PI  Bus  (Interoperability  Bus) 


Figure  3-14,  VHSIC  TM/ETM/PI  Buses 

The  Test  and  Maintenance  (TM)  Bus  [10]  provides  a  communication  path  between  the 
board  maintenance  controller  and  a  subsystem  maintenance  controller.  The  TM  Bus 
functions  to  transfer  test  control/data  to  and  from  the  higher  level  controller.  Simi¬ 
larly,  each  of  the  subsystem  controllers  can  be  connected  via  a  system  maintenance 
bus  to  a  system  level  controller  which  oversees  and  conducts  the  testing  of  the  overall 
system.  The  Element  Test  and  Maintenance  (ETM)  Bus  [ll]  accomplishes  the  same 
function  at  a  lower  level  of  the  design  hierarchy.  The  ETM  Bus  provides  a  serial  data 
path  to  transfer  test  data  and  control  information  between  the  board  level  mainte¬ 
nance  controller  and  the  maintenance  control  unit  built-in  to  a  VHSIC  chip  or  to  a 
module. 

The  incorporation  of  a  maintenance  bus  architecture  across  different  design  levels  is  an 
integral  part  of  a  structured  design  for  testability  methodology.  It  provides  a 


3-47 


systematic  procedure  to  conduct  and  coordinate  testing  at  the  various  operational  lev¬ 
els.  Each  maintenance  controller  is  responsible  for  performing  tests  at  its  level,  control 
the  testing  of  any  underlying  levels,  receive  and  process  any  error  messages,  and  com¬ 
municate  to  its  appropriate  master  controller.  At  the  system  level,  the  master  con¬ 
troller  is  the  operator.  Such  a  top-down  structured  approach  is  important  in  reducing 
the  time  and  costs  associated  with  detecting  and  isolating  faults  utilizing  built-in  mon¬ 
itoring  units. 

Built-in  testing  may  be  classified  as  one  of  two  types:  off-line  or  on-line.  Off-line  test¬ 
ing  makes  use  of  specific  test  data  which  is  applied  to  the  system  during  a  special  test 
mode  of  operation.  On-line,  or  concurrent  testing,  generally  makes  use  of  hardware 
redundancy  and  coding  techniques  to  test  the  system  during  normal  operation.  Thus, 
there  is  no  need  to  generate  test  data  for  concurrent  testing  since  it  uses  the  normal 
operational  data.  Since  redundancy  is  included  in  the  system  hardware,  the  occurrence 
of  a  fault  is  not  necessarily  fatal.  This  method  of  duplicating  hardware  in  a  configura¬ 
tion  to  improve  the  reliability  of  the  system  is  known  as  fault  tolerance.  Fault  tolerant 
systems  were  motivated  largely  by  the  desire  to  have  highly  reliable  space-based  sys¬ 
tems  since  they  are  virtually  inaccessible  for  normal  maintenance  procedures.  Consid¬ 
erable  efforts  are  now  underway  to  further  development  of  fault  tolerance  methods  and 
to  improve  their  cost  effectiveness. 

With  the  increasing  usage  of  complex  electronic  systems  in  every  facet  of  our  society,  it 
is  imperative  that  their  reliability  and  maintainability  be  improved.  One  must  now 
consider  the  total  life  cycle  costs  (LCC)  as  as  important  selection  criteria  when  choos¬ 
ing  a  system  for  a  particular  application.  It  has  been  observed  [12]  that  the  costs 
incurred  with  the  design  and  acquisition  of  a  system  are  less  than  50%  of  the  total 
LCC.  Therefore,  more  than  half  of  the  LCC  are  associated  with  system  logistics  costs. 
The  use  of  BIT  and  DFT  have  been  shown  to  be  cost  effective  and  instrumental  in 
reducing  the  development,  maintenance,  and  support  costs  of  modern  electronic  sys¬ 
tems. 

The  objective  of  TEA  is  to  develop  an  automated  top-down  methodology  utilizing 
built-in  test  and  design  for  testability  to  improve  system  maintenance  and  supportabil- 
ity.  It  will  be  used  to  aid  the  designer  who  is  not  a  testing  expert  to  effectively  assess 
the  cost  and  impact  of  a  particular  BIT  or  DFT  technique  on  his  design.  As  such,  it 
will  allow  him  to  meet  specific  testability  requirements  at  the  system,  subsystem,  and 
board  levels  that  will  result  in  an  overall  system  that  is  testable,  maintainable,  and 
supportable  by  construction. 
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3.4.2.  TEA  Board  Level  BIT  Techniques. 

TEA  supports  one  Implementation  of  each  of  seven  board  level  built-in  test  techniques, 
designed  to  achieve  fault  detection  and/or  fault  isolation  to  a  particular  set  of  chips 
determined  by  user  interaction  with  the  BIT  Recommendation  Tool  (Paragraph  2.7.2S. 
Tools  in  the  TEA  system  are  used  to  estimate  the  overhead  involved  in  adding  a  tech¬ 
nique  to  a  particular  board  (Paragraph  2.7.3)  and  to  give  instructions  for  adding  TEA’s 
support  BIT  modules  (Paragraph  3.4.3)  and/or  test  points  to  that  board  to  get  an 
updated  (testable)  representation.  VHDL  descriptions  of  the  BIT  modules  are  provided 
to  support  functional  simulation  of  the  system  with  added  BIT  features.  These 
modules  are  represented  by  ADAS  templates. 

The  techniques  are  provided  to  complement  the  TEA  testing  methodology  shown  in 
Figure  2-4.  BIT  support  modules  (or  test  points)  are  added  to  a  board  which  commun¬ 
icate  with  an  on-board  maintenance  node,  which  communicates  to  the  subsystem  test 
strategy. 

The  techniques  implemented  as  part  of  TEA  are  intended  for  application  to  board 
designs  of  digital  synchronous  circuitry.  The  techniques  are  applied  in  a  strict  manner 
of  adding  logic  (or  test  points)  to  accomplish  the  fault  isolation  requirement.  The  tools 
do  not  make  recommendations  for  replacing  logic  nor  do  they  tell  the  user  how  to  per¬ 
form  tests;  however,  the  BIT  support  module  application  notes  show  examples  of 
accepted  methods.  Typically  these  techniques  facilitate  fault  isolation  to  an  ambiguity 
group  plus  the  BIT  support  modules  added  for  that  group. 

A  maintenance  node  is  recommended  for  each  board:  however,  the  tools  do  not  make 
recommendations  about  connecting  the  maintenance  node  to  the  on-board  BIT  circui¬ 
try  because  this  depends  a  great  deal  on  how  the  user  decided  to  test  his  system.  The 
Maintenance  Node  application  note  shows  examples  of  different  testing  styles. 

In  some  cases  there  are  many  possible  implementations  of  a  general  BIT  technique: 
only  one  has  been  selected  for  each.  The  chosen  implementation  may  result  in  very 
high  overhead  (e.g.,  test  modules,  additional  control  lines)  that  makes  the  technique 
appear  unacceptably  costly,  but  this  technique  should  not  be  ruled  out  entirely.  In 
some  cases  a  combination  of  techniques  may  result  in  the  best  overall  testability  and 
the  lowest  cost.  TEA  does  not  consider  combinations  of  its  techniques  in  itemized  cost 
lists,  but  they  could  be  used  when  getting  an  updated  schematic.  Appendix  B  shows 
diagrams  of  other  possible  implementation  of  the  TEA  techniques.  These  are  included 
for  the  informational  use  only;  they  have  not  been  implemented  as  part  of  TEA.  The 
user  could  use  these  diagrams  for  manual  addition  of  a  particular  technique  to  a  board 
since  the  modules  needed  are  in  the  BIT  module  data  base  and  the  ADAS  templates 
are  provided. 

Non-optimal  use  of  BIT  support  modules  may  also  contribute  to  high  cost  estimates. 
TEA  has  a  support  library  of  modules  expecting  a  16-bit  data  path.  If  the  data  path  is 
18  bits,  for  example,  the  TEA  tools  recommend  “ganging”  two  full-sized  modules 
together,  underutilizing  at  least  one  of  the  modules.  The  user  could  possibly  deter¬ 
mine  two  bits  of  that  path  that  would  not  require  observation,  thus  saving  the 
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overhead  associated  with  that  module. 

A  single  example  is  used  throughout  the  rest  of  this  paragraph  to  illustrate  the  TEA 
techniques.  Figure  3-15  shows  a  simple  system  consisting  of  three  undetermined  size 
(number  of  chips)  ambiguity  groups  (AG)  which  are  highly  interconnected.  Each  .\G 
is  connected  to  both  of  the  others.  Each  AG  accepts  input  from  the  board  edge  and 
delivers  output  to  the  board  edge.  This  example  does  not  show  any  special  AGs  (Para¬ 
graph  2.6.1),  but  any  of  the  AGs  could  be  considered  special.  Simple  one-line  intercon¬ 
nections  are  shown  for  the  purposes  of  illustration. 


board  edge 


Figure  3-15.  Board  with  No  BIT  Technique  Applied. 


This  paragraph  describes  each  of  the  techniques.  Instructions  for  running  the  tools  are 
found  in  the  TEA  User  Manual. 

Continuous  Test  Point  Monitoring  is  abbreviated  det_tp  in  the  tool  menus.  This  is 
an  off-line  testing  technique.  Figure  3-16  shows  how  this  technique  is  applied  to  the 
example  board  shown  in  Figure  3-15.  det_tp  adds  no  BIT  support  modules  besides 
the  maintenance  node.  Test  points  are  added  at  ambiguity  group  boundaries,  except 
at  board  outputs.  TEA  optimizes  the  number  of  test  points  for  high  testability  and 
low  overhead  and  gives  exact  locations. 

Careful  selection  of  a  test  program  set  can  eliminate  the  need  for  test  points,  but  pro¬ 
cedures  for  doing  so  are  not  supported  in  TEA  since  test  programs  are  not  required  to 
run  TEA. 
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X  indicates  test  point  output 


Figure  3-16.  BIT  Technique  1-a:  Test  Point  Monitoring  —  Continuous 

(Cycle  by  Cycle). 


This  technique  does  not  do  any  test  pattern  generation,  so  it  can  support  both  deter¬ 
ministic  and  pseudorandom  testing. 

Test  Point  Monitoring  with  Data  Compression  is  abbreviated  tpjsa  in  the  tool  menus. 
This  is  an  off-line  testing  technique.  Figure  3-17  shows  how  this  technique  is  applied 
to  the  example  board  shown  in  Figure  3-15.  tp_sa  adds 

a.  pseudorandom  test  pattern  generators  (TPG)  (exclusive-or  implementation)  for 
intercepting  incoming  data  lines 

b.  scan-set  registers  for  intercepting  incoming  control  lines 

c.  built-in  logic  block  observers  (BILBOs)  to  compress  output  lines  into  signa¬ 
tures 

d.  multiplexors  as  appropriate  so  that  no  more  TPGs  and  BILBOs  than  necessary 
are  added  to  the  design 

Clock  lines  are  not  trapped  and  brought  through  BIT  modules. 

The  overhead  for  this  technique  could  be  quite  high.  Each  TPG  has  an  associated 
multiplexor.  There  is  at  least  one  TPG,  Multiple  TPGs  are  needed  if  the  data  path  is 
>  16  bits.  Highly  connected  AGs  further  penalize  the  overhead  because  enough  multi¬ 
plexors  are  needed  to  break  feedback  paths.  Scan-set  modules  are  needed  for  each  AG 
that  has  control  inputs.  These  modules  do  not  need  multiplexors  since  the  library 
model  has  normal  and  “test”  modes.  Each  set  of  lines  that  need  to  be  compressed  go 
to  a  multiplexor  port  and  each  of  these  output  multiplexors  has  a  BILBO  associated 
with  it.  Data  lines  are  kept  separate  from  control  lines  going  to  these  output  multi¬ 
plexors.  AGs  may  have  multiple  data  and  control  sets  because  the  techniqiie  keeps 
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lines  going  to  a  particular  AG  separate  from  lines  going  to  a  different  AG  and  these  are 
all  icept  separate  from  lines  leaving  the  board.  If  less  than  total  isolation  can  be 
tolerated,  it  is  recommended  that  r.hese  restrictions  be  relaxed. 

This  technique  supports  pseudorandom  test  pattern  generation  on  the  ilata  inputs  and 
unrestricted  control  of  the  control  lines. 

Board  Level  Boundary  Scan  is  abbreviated  boundary  in  the  tool  menus.  This  is  an 
off-line  testing  technique.  Figure  3-18  shows  how  this  technique  is  applied  to  the 
example  board  shown  in  Figure  3-15.  boundary  adds 

a.  scan-set  registers  for  intercepting  incoming  control  lines 

b.  scan-set  registers  for  intercepting  incoming  data  lines  and  outgoing  board  sig¬ 
nals 

This  technique  has  relatively  low  overhead  associated  with  it,  but  fault  isolation  to  the 
AG  is  no  longer  guaranteed  unless  the  user  has  a  carefully  selected  test  program  set 
and  the  order  of  application  of  those  test  sets  is  carefully  controlled.  This  technique 
keeps  data  and  control  lines  separate.  All  board  outputs  are  routed  back  to  the  scan- 
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Figure  3-17.  BIT  Technique  2-a:  Test  Point  Monitoring  —  Data  Compression 


set  registers  used  to  intercept  incoming  data  lines  so  there  is  overhead  associated  with 
high  number  of  board  outputs  compared  to  data  input  lines. 

This  technique  does  not  generate  test  patterns  for  the  circuit,  so  predetermined  test 
patterns  would  either  have  to  be  stored  for  the  board  or  generated  off-board  and 
applied  serially  through  the  scan-set  registers. 

This  technique  supports  deterministic  testing. 

Scan-Set  is  abbreviated  scan_set  in  the  tool  menus.  This  is  an  off-line  testing  tech¬ 
nique.  Figure  3-19  shows  how  this  technique  is  applied  to  the  example  board  shown  in 
Figure  3-15.  scanjset  adds 

a.  scan-set  registers  for  intercepting  incoming  control  lines 

b.  scan-set  registers  for  intercepting  incoming  data  lines 

c.  scan-set  registers  for  intercepting  internal  data  lines  which  feed  another  AG 

d.  scan-set  registers  for  intercepting  internal  control  lines  which  feed  another  AG 

All  lines  go  from  a  scan-set  module  to  the  AG  both  in  normal  and  “test”  modes.  No 
line  will  (except  clocks)  enter  an  AG  if  it  has  not  been  fed  through  a  scan-set  module. 
All  lines  leaving  an  AG  are  fed  back  to  the  scan-set  module  which  provided  the  input 
to  the  AG  so  there  is  some  overhead  associated  with  providing  for  the  larger  of  those 
counts  for  each  AG.  All  feedback  and  fanout  paths  are  broken  to  further  aid  fault  iso¬ 
lation  to  an  AG  and  accompanying  scan-set  modules.  All  AG  outputs  which  leave  the 
board  are  also  fed  back  to  the  AG  input  registers.  In  all  cases,  data  and  control  lines 
are  kept  separate. 

Careful  control  of  the  test  program  set  is  needed  as  the  user  will  want  to  serially  test 
each  AG  while  the  other  AGs  are  in  normal  mode. 

This  technique  does  not  generate  test  patterns  for  the  circuit,  so  predetermined  test 
patterns  would  either  have  to  be  stored  for  the  board  or  generated  off-board  and 
applied  serially  through  the  scan-set  registers. 

Test  Pattern  Generation  with  Data  Compression  is  abbreviated  genjsa  in  the  tool 
menus.  This  is  an  off-line  testing  technique.  Figure  3-20  shows  how  this  technique  is 
applied  to  the  example  board  shown  in  Figure  3-15.  genjsa  can  add 

a.  testing  switches  (TSWITCH)  for  intercepting  incoming  control  lines 

b.  TSWITCHes  for  intercepting  incoming  data  lines 

c.  TSWITCHes  for  intercepting  internal  data  lines  which  feed  another  AG 

d.  TSWITCHes  for  intercepting  internal  control  lines  which  feed  another  AG 

e.  TSWITCHes  for  intercepting  data  lines  leaving  the  board 

f.  TSWITCHes  for  intercepting  control  lines  leaving  the  board 
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Figure  3-19.  Bit  Technique  4-a;  Scan-set  Technique  Using  Scan-set  BIT 
Modules  Distributed  over  the  Board. 
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Figure  3-20.  Bit  Technique  5-a;  Test  Pattern  Generation  and  Response 
Compression  Using  “Testing  Switch”  Modules  Distributed  over  the  Board. 
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The  TSWITCHes  which  precede  an  AG  generates  the  input  vectors  for  the  AG.  The 
TSWITCHes  whicn  follow  an  AG  analyzes  the  output  vectors  from  the  AG.  All  lines 
go  from  a  TSWITCH  module  to  the  AG  both  in  normal  and  ‘‘test”  modes.  No  line 
(except  clocks)  will  enter  an  AG  if  it  has  not  been  first  fed  through  a  TSWITCH 
module.  All  lines  leaving  an  AG  are  fed  forward  to  the  TSWITCH  module  which  pro¬ 
vides  the  input  to  the  next  AG(s).  All  feedback  and  fanout  paths  are  broken  to 
further  aid  fault  isolation  to  an  AG  and  accompanying  TSWITCH  modules  and  this  is 
done  with  just  one  TSWTTCH  delay.  All  AG  outputs  which  leave  the  board  are  also 
fed  to  a  TSWITCH  module.  In  all  cases,  data  and  control  lines  are  kept  separate. 

Careful  control  of  the  test  program  set  is  needed  as  the  user  will  want  to  test  each  AG 
while  other  AGs  are  in  normal  mode.  A  single  TSWITCH  is  capable  of  simultaneously 
generating  patterns  for  one  AG  while  compressing  patterns  received  from  another. 

This  technique  can  support  both  pseudorandom  and  deterministic  test  pattern  genera¬ 
tion  on  both  the  data  and  control  lines. 

Parity  Check/Generate  is  abbreviated  parity  in  the  tool  menus.  This  is  an  on-line,  or 
concurrent  testing  technique,  meaning  that  testing  can  be  accomplished  during  opera¬ 
tion  of  the  system.  Figure  3-21  shows  how  this  technique  is  applied  to  the  example 
board  shown  in  Figure  3-15. 

This  technique  is  supported  differently  from  the  five  techniques  described  above.  No 
estimation  of  overhead  costs  is  performed  for  this  technique  because  from  strict  topo¬ 
logical  information  available  to  TEA,  TEA  does  not  make  decisions  about  where 
modules  are  needed  to  generate  or  check  the  parity  of  a  device.  The  user  is  directed  to 
texts  describing  coding  theory  and  practical  application  of  parity. 

TEA  allows  the  straight-forward  addition  of  the  “parity”  library  module  to  a 
schematic  by  requesting  the  user  to  only  specify  the  lines  to  which  the  module  should 
be  attached.  TEA  will  automatically  reroute  the  arcs  and  add  the  nodes  to  the  graph. 
The  user  will  then  have  to  make  the  graph  “pretty”  again. 

Test  patterns  are  functional  input  patterns,  as  this  is  an  on-line  technique. 


8-bit  bus 


reference 


check  bit 


Figure  3-21.  BIT  Technique  6:  Parity  Generation/Checking. 
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On-line  Comparison  of  Duplicated  Modules  is  abbreviated  compare  in  the  tool 
menus,  except  on  the  top-level  TEA  menu,  where  compare  refers  to  the  System  Sum¬ 
mary  tool  (Paragraph  2.7.5).  This  is  an  on-line,  or  concurrent  testing  technique,  mean¬ 
ing  that  testing  can  be  accomplished  during  operation  of  the  system.  Figure  3-22 
shows  how  this  technique  is  applied  to  the  example  board  shown  in  Figure  3-15. 


Figure  3-22.  BIT  Technique  7;  Selective  Duplication. 
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This  technique’s  support  is  identical  to  the  technique  identified  as  parity.  No  estima¬ 
tion  of  overhead  costs  is  performed  for  this  technique  because  from  strict  topological 
information  available  to  TEA,  TEA  does  not  make  decisions  about  where  duplication 
of  modules  is  needed  to  provide  fault  detection  (and  perhaps  other  fault  tolerance) 
capabilities.  The  user  is  directed  to  texts  describing  the  use  of  module  duplication  as  a 
form  of  on-line  fault  detection.  Duplication  and  comparison  will  not  aid  in  fault  isola¬ 
tion  because  if  an  error  is  indicated  at  the  output  of  the  comparator,  the  user  still 
doesn't  know  if  the  error  occurred  in  the  “functional”  module  or  the  “duplicated" 
module. 

TEA  allows  the  straight-forward  addition  of  the  “compare”  library  module  to  a 
schematic  by  requesting  the  user  to  only  specify  the  lines  to  which  the  module  should 
be  attached.  TEA  will  automatically  reroute  the  arcs  and  add  the  nodes  to  the  graph. 
The  user  will  then  have  to  make  the  graph  “pretty”  again. 

Test  patterns  are  functional  input  patterns,  as  this  is  an  on-line  technique. 

3.4.3.  TEA  BIT  Support  Modules.  Appendix  C  describes  the  details  of  each  of  the  BIT 
support  modules  provided  with  TEA  in  the  form  of  application  notes.  The  group  of 
modules  forms  a  library  or  data  base.  With  this  library,  the  user  receives 

a.  an  application  note  describing  the  function  of  the  module  along  with  an  exam¬ 
ple  implementation  and  notes  on  using  the  module  in  a  testing  situation 

b.  an  ADAS  template  to  use  when  adding  nodes  representing  BIT  support 
modules  into  a  graph 

c.  VHDL,  version  7.2,  and  IEEE  1076  structural  and/or  behavioral  descriptions  of 
the  module 

d.  a  gate  level  description  of  the  model  entered  in  CADAT  (product  of  HHB- 
Systems  of  Mahwah,  NJ)  format 

The  BIT  Overhead  Summary  (Paragraph  2.7.3)  and  BIT  Placement  Recommendation 
(Paragraph  2.7.4)  tools  use  the  library  to  pick  out  modules  to  support  the  BIT  tech¬ 
nique  chosen  by  the  user. 

In  many  cases,  a  second  version  of  each  BIT  module  (referred  to  as  version  2)  is  sup¬ 
plied.  This  second  version  has  been  built  to  interface  to  the  maintenance  node 
delivered,  without  additional  functionality.  The  version  2  modules  will  not  automati¬ 
cally  be  added  to  a  system  by  the  TEA  tools. 
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4.  EXAMPLE  USE  OF  TEA 

The  following  is  an  example  of  the  use  of  the  TEA  tools.  Figure  4-1  is  the  .ADAS 
representation  of  the  system  under  consideration. 


prod_20.hwg 


Figure  4-1.  ADAS  Graph  of  Doppler  Filter  Card  of  the  Radar  Signal 

Processor  of  Firefinder 
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Output  from  the  tools  is  in  regular  type.  User  responses  are  shown  in  bold  typeface. 
Commentary  will  be  shown  in  italics. 

TERMINAL  SESSION 


$  tea  prod_20.h'wg  -d  vsii 

The  user  has  entered  the  graph  name  (prod_20.hwg)  and  graphics  display  on  the  command  line.  This 
refers  to  the  DEC  VAXstation  11. 


*  * 

*  ADAS:  Architecture  Design  and  Assessment  System  * 

*  Copyright  1985,  1986,  1987  by  Research  Triangle  ♦ 

*  Institute.  * 

*  * 

*  Tea  (version  PROTO. TYPE)  * 

*  * 

*  Proprietary  Software.  All  rights  reserved.  * 

*  No  part  of  this  software  may  be  sold  * 

*  or  distributed  In  any  form  or  by  any  means  * 

*  without  the  prior  written  permission  of  * 

*  the  Research  Triangle  Institute.  * 

*  * 


Getting  database  . . . 


The  user's  hardware  graph  file  is  loaded  into  the  data  base. 

===  menu 
quit 
save 
edit 
move 
dft 


command^  dft 

This  is  the  TEA  top-level  menu.  The  user  has  selected  the  Design  for  Testability  Guideline  Checker  from 
the  menu. 


brt 

blt_cost 

placeblt 

compare 

ag_name 


log_f lie 

window 

environ 

stats 

subgraf 


hardcopy 

script 

macro 

reload 

help 
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===  menu  === 
5iHelp 
analyze 
identify 
explain 


DFT;  Select  a  DFT  option  to  be  executed:  analyze 

The  first  menu  the  user  encounters  is  the  dft  action  menu.  Here  the  user  has  selected  to  analyze  his 
graph  for  untestable  or  hard-to-test  structures. 

===  menu  === 

%help 
standard 
user  rules 


DFT:  Select  the  type  of  rules  to  use:  standard 
The  user  wants  to  select  from  the  guidelines  provided  with  TEA. 


===  menu  === 


Kdone 

gl  02 

gl_08 

gl  14 

Khelp 

gl_03 

gl  09 

gl  15 

Kail 

gl  04 

gl  10 

gl_16 

Kail  gl 

gl  05 

gl  11 

g2_01 

Kali  g2 

gl  06 

gl  12 

gi.oi 

gl_07 

gl_13 

Enter 

to  view  additional  menu 

Items 

DFT:  Select  the  guldellne(s)  to  be  executed:  gl_02  %done 

The  only  guideline  selected  is  gl_02:  Make  preset/clear  a  primary  input  or  primary  input  controllable. 
Note  that  the  user  must  select  the  %done  option  to  exit  this  menu. 

===  menu  === 

Xdone 

Rhelp 

Kail 

radar 


DFT:  Indicate  the  subsystem(s)  of  Interest:  radar  %done 


Kdone 

Khelp 

Kail 

doppler 


DFT:  Indicate  the  board(s)  of  Interest:  doppler  %done 
The  doppler  board  of  the  radar  subsystem  has  been  selected  for  analy.sis. 
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****  Running  prolog  code  ***♦ 

[compiling  project:  [tea.jrc.demolgrapti.pl.  .  .] 

[graph.pl  compiled  334.350  sec  77,072  bytes] 

[compiling  project:  [tea. j rc . demo] control . pi . . .] 

[control.pl  compiled  0.980  sec  496  bytes] 

Run  analyze  rules 
running  gl_02 

***  gl_02  VIOLATION  -->  rl  U22  port=7  clear 

***  gl_02  VIOLATION  — >  rl  U24  port=7  clear 

***  8l_02  VIOLATION  — >  rl  U25  port=7  clear 

Exiting  the  board  menu  starts  the  execution  of  dft.  Dft  is  implemented  in  prolog,  so  the  graph  data  base 
must  be  translated  into  prolog  for  comparison  to  the  guidelines,  graph.pl  is  the  prolog  representation  of 
the  graph  data  base,  control.pl  is  the  prolog  representation  of  the  input  the  user  has  given  to  dft  (e.g.. 
board  name,  guidelines). 

Enter  <cr>  or  YES  to  accept  dft_01.rpt  as  the  default  filename 
Or  enter  desired  output  filename  :  gl_02 


The  user  has  selected  to  name  his  output  report  gl_02  rather  than  accept  the  default  name  selected  by  the 
tool. 


===  menu  === 


quit 

brt 

log_file 

save 

blt_cost 

window 

edit 

placeblt 

environ 

move 

compare 

stats 

dft 

ag_name 

subgraf 

hardcopy 

script 

macro 

reload 

help 


command^  log_file 

Once  the  tool  completes,  process  control  is  returned  to  the  top-level  menu.  The  user  now  selects  the 
report  access  utility. 


Shelp 

view 

print 


Log_flle:  View  or  print  report?  view 

Enter  directory  path  to  search. 

<cr>  or  YES  searches  current  dir:  yes 


===  menu  === 
%help 
gl_02 . rpt 


Logfile:  Select  a  report:  gl_02.rpt 
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The  user  has  selected  to  new  the  file  railed  glj)2.rpt  in  his  current  directory.  This  ;s  ihe  nntorit  of  the 
•ml  to  dft  that  :ras  just  completed . 


Test  £ng:.neer's  Assistant  (TEA)  Output  Report 

ADAS/TEA  Version:  PRGTO.TYPE 
Researca  Triangle  Institute 
?.0.  3ox  12194 

Research  Triangle  ParJc,  NC  27709 
Date/Tlae:  Wed  Sep  21  06:16:41  1988 

User:  JRC 
Graph : 

Current  Vlevr  Graph:  Doppler_Filter_3oard 

Current  View  Filename:  PRO  JECT :  [TEA .  JRC ,  DEMO]  PR0D_20  ,  H'.vG  ,  1 

Output  Report  Filename  =  PRO JECT : [TEA . JRC . DEMO] Gl_02 . RPT ; 1 


DESIGN  FOR  TESTABILITY  GUIDELINE  CHECKER 
(dft  analyze) 


Where 

Subsystem- 

radar 


Board- 

doppler 

Guidelines  Selected- 
gl_02 


Gl_02 

G1_02_REC  -  To  aid  test  pattern  generation,  the 
PRESET  or  CLEAR  input  of  flip_flops,  counters  and 
shlf t_registers  should  be  directly  controllable. 
Port  ’clear’  (port=7)  of  node  ’U22’ 
is  a  PRESET/CLEAR  line  that  is  not  primary  Input 
controllable.  Make  this  port  (port=7)  primary  input 
controllable . 
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G1_02_REC  -  To  aid  test  pattern  generation,  the 
PRESET  or  CL.EAR  input  of  :lip_flops,  counters  and 
shif t_registers  should  be  directly  controllable. 
Port  ’clear’  (port=7)  of  node  ”J24 ’ 

IS  a  PRESET, CLEAR  line  that  is  not  primary  input 
controllable.  .Make- this  port  (port=7)  primary  input 
controllable . 


G1_02_REC  -  To  aid  test  pattern  generation,  the 
PRESET  or  CLEAR  input  of  flip_flops.  counters  and 
shif t_registers  should  be  directly  controllable. 
Port  'clear'  (port=7)  of  node  ’U25' 
is  a  PRESET/CLEAR  line  that  is  not  primary  input 
controllable.  Make  this  port  (port=7)  primary  input 
controllable . 


Flip_flops.  Counters,  and  Shif t_registers 

UlO  Ull  U12  U13  U14  U15  U16  U18  U2 

U22  U24  U25  U4  US  U6  U7  U8  U9 

There  were  3  violations  found 

dft  analyze  Completed 


The  output  shows  all  the  registers,  flip  flops,  counters  found  in  the  graph.  The  nodejnames  of  the  nodes 
are  shown  as  a  list.  In  addition  to  this  list,  the  violations  and  recommendations  are  shown. 


===  menu  === 

quit 

brt 

log  file 

hardcopy 

save 

bit  cost 

window 

script 

edit 

placebit 

environ 

macro 

move 

compare 

stats 

reload 

dft 

ag_naine 

subgraf 

help 

command^  dft 

===  menu  === 

%help 

analyze 

identify 

explain 

DFT:  Select  a  DFT 

option  to  be 

executed :  identify 

user  ha.‘:  entered  dft  again,  this  time  selec 

ting  the  identify  function. 
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%doQe 

5{lielp 

%a.ll 

radar 


DFT;  Indicate  the  subsystem (s)  of  Interest;  radar  %done 


Xdone 
She  Ip 
Sail 
doppler 


DFT:  Indicate  the  board (s)  of  Interest:  doppler  %done 


===  menu 

Shelp 

attribute 

blt_mod 

counter 


f anout>5 
fllpflop 
loop 
memory 


node 

one_shot 

primaries 

processor 


DFT:  Select  an  Item  to  be  Identified:  fanout>5 


register 

scan_reg 

test_polnt 


The  user  has  instructed  the  tool  to  look  for  oecurranees  of  fanout  >  5  on  the  doppler  board  of  the  radar 
subsystem. 


Enter  <cr>  or  YES  to  accept  dft_01.rpt  as  the  default  filename 
Or  enter  desired  output  filename  ;  doppler_fanout 

The  results  of  this  action  will  be  itemized  in  doppler Janout.rpt. 


===  menu  == 
quit 

brt 

log_f lie 

hardcopy 

save 

blt_cost 

window 

script 

edit 

placeblt 

environ 

macro 

move 

compare 

stats 

reload 

dft 

ag  name 

subgraf 

help 

commands  dft 

===  menu  === 
Shelp 
analyze 
Identify 
explain 

DFT:  Select  a 

DFT  option  to  be 

executed;  explain 
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===  menu  === 
%help 
gl 

g2 


DFT:  Select  the  appropriate  guideline  group:  gl 


===  menu  === 

?{help  gl_05  gl_10  gl_15 

gl_01  gl_06  gl_ll  gl_16 

gi_02  gl_07  gl_12 

gl_03  gl_08  gl_13 

gl_04  gl_09  gl_14 


DFT:  Select  the  specific  guideline  to  be  explained:  gl_02 
The  kelp  file  information  concerning  gl_02  will  be  accessed  through  use  of  the  explain  function  of  dft. 


===  menu  === 
?{help 
yes 
no 


DFT:  Store  the  explanation  to  a  file?  no 
The  results  are  displayed  on  the  screen. 

TOOLS 

DFT_Checker 
Rules 
Gl  02 


Gl_02  Rule:  Make  Preset/Clear  a  primary  input  or  primary 
input  controllable. 

Why? 

Because  this  provides  direct  control  of  the  Initializa¬ 
tion  function  to  the  tester  and  can  be  used  to  initialize 
several  circuits  at  once  with  a  single  pulse  during  test. 

How? 

(a)  Avoid  preset  and  clear  being  tied  together  through 
a  resistor  to  VDD.  Although  the  tester  can  access  the  point 
(a  primary  input)  to  Initialize  this  component,  the  outcome 
will  be  indeterminate  when  the  tester  releases  the  test 
point. 

(b)  Do  one  of  these. 
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(i)  Make  the  clear  input  a  primary  input  or  primary  input 
controllable.  The  tester  can  access  this  input  directly  or 
through  other  controlling  circuitry. 

(ii)  Make  the  clear  line  an  arbitrary  signal  gated  with  a 
primary  input  which  is  connected  with  VDD  through  a  resis¬ 
tor.  The  tester  accesses  the  primary  input  and  clears  the 
circuit  with  override. 

(lii)  Make  the  clear  line  an  arbitrary  signal  gated  with  a 
primary  input  which  is  connected  with  VDD  through  a  resistor 
and  VSS  through  a  capacitor.  The  circuit  clears  with  tester 
override  and  also  on  power-up. 

Syntax 


lnport_ld:  preset,  pre,  clear,  clr 

Tarc_type:  data,  control,  cntrl,  Ctrl,  clock,  elk 

Tdft_lo;  primary_lnput,  pi,  prlmary_output,  po, 
test_polnt,  test_polnt_output,  test_pt_output,  tp,  tpo 

Tloglc_type :  combinational,  comb_logic,  comb 

Tnode_type;  fllp_flop,  flipflop,  ff,  counter,  ctr, 
shift_register ,  sr,  shiftreglster 


Topic?  <CR> 

The  user  types  a  carriage  return  to  exit  the  help  files. 

===  menu 
quit 
save 
edit 
mpve 
dft 


command^  brt 

Now  the  user  has  selected  to  enter  the  BIT  Recommendation  Tool. 

===  menu  === 

Xhelp 

radar 


brt 

blt_cost 

placeblt 

compare 

ag_name 


log_f lie 

window 

environ 

stats 

subgraf 


hardcopy 

script 

macro 

reload 

help 


BRT:  Indicate  the  subsystem  of  Interest;  radar 
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===  menu  === 
%belp 
doppler 


BRT:  Indicate  the  board  of  interest;  doppler 
BRT:  Enter  desired  AG  size;  3 


===  menu  === 
Xhelp 
yes 
no 


BRT:  Alter  cost  function  to  account  for  testability?  yes 


The  possible  groups  of  size  3  and  less  of  the  doppler  board  will  be  considered  for  their  testability.  .4  modi¬ 
fied  cost  function  will  be  used  to  find  a  minimum  cost  solution.  A  testing  recommendation  will  be 
assigned  to  each  node  and  to  each  ambiguity  group. 


Enter  <cr>  or  YES  to  accept  brt_01.rpt  as  the  default  filename 
Or  enter  desired  output  filename  ;  brt_doppler_size3 


Finding  ambiguity  groups  .  .  . 

Finding  optimal  configuration  of  ags 
The  results  are  stored  in  an  output  file. 


===  menu  === 
quit 

brt 

log_f  ill 

save 

bit  cost 

window 

edit 

placeblt 

environ 

move 

compare 

stats 

dft 

ag_name 

subgraf 

command^  bit  cost 


hardcopy 

script 

macro 

reload 

help 


===  menu  === 
Xhelp 
radar 


Blt_cost:  Indicate  the  subsystem  of  interest:  radar 


===  menu  === 
5thelp 
doppler 


Blt_cost;  Indicate  the  board  of  interest:  doppler 
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The  costs  of  implementing  BIT  on  the  doppler  board  with  ambiguity  groups  as  assigned  by  brt  will  be 
estimated  by  the  BIT  Overhead  Summary  tool. 

===  menu  === 

%done  %all  tp_sa  scan_set 

%help  det_tp  boundary  gen_sa 


Bit_cost:  Select  BIT  technique (s) ;  tp_sa  9Zdone 

Enter  <cr>  or  YES  to  accept  bltcost_01 . rpt  as  the  default  filename 
Or  enter  desired  output  filename  ;  bitcost_tp_sa 


Enter  <cr>  or  YES  to  accept  bltcost_01 . dwg  as  the  default  filename 
Or  enter  desired  output  filename  :  bitcost_tp_sa 


The  results  of  running  bitjcost  on  the  doppler  with  the  Test  Point  Monitoring  with  Data  Compression 
technique  will  be  written  to  the  files  called  bitcost_tp_sa.rpt  and  bitcost_tp_sa.dwg. 

===  menu 
quit 
save 
edit 
move 
dft 


command^ 

===  menu 

Khelp 

det_tp 


Placeblt:  Select  a  BIT  technique:  tp_sa 

Confident  that  tp_sa  is  the  BIT  technique  of  choice,  the  user  has  entered  the  BIT  Placement  Recommen¬ 
dation  tool  and  selected  tp_sa. 

===  menu  === 

J(help 

yes 

no 


brt 

log_f lie 

hardcopy 

blt_cost 

window 

script 

placeblt 

environ 

macro 

compare 

stats 

reload 

ag_name 

subgraf 

help 

placeblt 

tp_sa 

scan_set 

parity 

boundary 

gen_sa 

compare 

Placeblt:  Do  you  want  TEA  to  attempt  an  example  Implementation?  yes 
This  indicates  that  the  user  wants  more  than  general  instructions  about  the  technique  he  has  chosen. 

===  menu  === 

?{help 

yes 

no 


Placeblt:  Add  nodes  to  supply  constant  0/1  values?  yes 
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When  the  graph  ia  updated,  all  input  data  linea  of  the  BIT  modulea  will  have  an  input  value  attached. 

===  menu  === 

Xhelp 

radar 


Placeblt;  Indicate  tie  subsystem  of  Interest:  radar 


===  menu  === 
JJbelp 
doppler 


Placeblt:  Indicate  the  board  of  Interest:  doppler 


==  menu  === 
Kdone 
%help 
«all 

autoplace 

wlrellst 


Placeblt;  Place  and/or  supply  manual  wiring  list?  wirelist  %done 

The  uaer  haa  not  ehoaen  to  have  hia  graph  automatically  updated,  rather  he  haa  aeleeted  to  get  a  wireliat 
30  that  manual  implementation  of  the  technique  could  be  achieved. 


Enter  <cr>  or  YES  to  accept  placeblt_01 .rpt  as  the  default  filename 
Or  enter  desired  output  filename  :  placebit_doppler_tp_sa 

General  wiring  information  and  error  reporta  are  given  in  the  .rpt  output  file. 


Enter  <cr>  or  YES  to  accept  placeblt_01 . dwg  as  the  default  filename 
Or  enter  desired  output  filename  :  placebit_doppler_tp_sa 

Specific  wiring  information  ia  given  in  the  .dwg  output  file. 

Some  changes  to  the  graphs  were  recommended. 

The  tool  ia  indicating  that  the  wiring  Hat  ia  not  empty. 


quit 

save 

edit 

move 


dft 


brt 

blt_cost 

placeblt 

compare 

ag_name 


log_f lie 

window 

environ 

stats 

subgraf 


hardcopy 

script 

macro 

reload 

help 


command^  compare 

The  uaer  wanta  aome  atatiatiea  concerning  hia  graph(a),  ao  he  haa  entered  the  Syatem  Summary  tool. 
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Enter  directory  path  to  search. 

<cr>  or  YES  searches  current  dir:  yes 


===  menu  === 

%help  system_2.hwg 

%self  system_3.hwg 

system_l.hwg  system_4.hwg 

Compare;  Select  the  comparison  graph;  %selt 

The  list  of  hardware  graph  files  in  the  current  directory  is  presented.  The  user  has  chosen  to  only  get 
output  concerning  his  "current  view"  graph  and  about  no  others. 

Enter  <cr>  or  YES  to  accept  compare_01 . rpt  as  the  default  filename 
Or  enter  desired  output  filename  ;  compare_self 

A  chart  of  statistics  about  the  graph  is  shown  in  the  .rpt  output  file.  This  includes  number  of  BIT 
modules,  number  of  test  points,  and  mean  time  to  test. 


Enter  <cr>  or  YES  to  < ccept  compare_01 . dwg  as  the  default  filename 
Or  enter  desired  output  filename  :  compare_self 

A  breakdown  of  the  ambiguity  groups  and  board  inputs/outputs  are  listed  in  the  .dwg  output  file. 


Some  errors  were  detected  in  the  graphs, 
check  the  report  for  details. 

The  tool  indicates  that  some  error  messages  will  appear  in  the  .rpt  file. 


quit 

save 

edit 

move 

dft 


hrt 

bit_cost 

placeblt 

compare 

ag_name 


command^  quit  nosave 


log_flle 

window 

environ 

stats 

subgraf 


hardcopy 

script 

macro 

reload 

help 


Exiting  the  tool  is  done  by  selecting  quit  from  the  top~level  menu.  No  changes  made  to  the  graph  (There 
should  have  been  none  anyway,  in  this  case.)  during  the  session  will  be  saved  since  the  user  has  selected 
to  nosave  his  data  base. 
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5.  NOTES 


5.1.  Glossary. 

aid  to  test  pattern  application.  Some  design  for  testability  guidelines  are  in  the  data 
base  to  aid  test  pattern  application.  These  guidelines  generally  ease  the  controllability 
of  clocks  and  significant  control  functions  of  a  system  so  that  automatic  test  equip¬ 
ment  can  be  used  to  externally  control  the  system  during  test  mode. 

aid  to  test  pattern  generation.  Some  design  for  testability  guidelines  are  in  the  data 
base  to  aid  test  pattern  generation.  These  guidelines  generally  increase  controllability 
and  observability  of  nodes  buried  within  a  system. 

ambiguity  group  (AG),  the  smallest  group  of  items  to  which  a  fault  can  be  isolated 

analog  node,  a  node  that  has  not  been  identified  as  digital.  An  analog  node  has  its 
Tdevice_type  set  to  a,  analog.  A  node  with  no  Tdevice_type  value  is  digital. 

built-in  test  (BIT),  a  particular  design  for  testability  technique  that  requires  that  some 
technique  for  detecting  faults  be  provided  in  addition  to  the  function 

built-in  test  techniques.  TEA  has  a  data  base  of  seven  particular  BIT  techniques. 
These  include 

a.  continuous  test  point  monitoring,  can  support  both  deterministically  and  pseu- 
dorandomly  generated  test  patterns 

b.  test  point  monitoring  with  data  compression,  supports  deterministic  test  pat¬ 
terns  for  control  lines  and  pseudorandomly  generated  test  patterns  for  data 
lines 

c.  board  level  boundary  scan,  supports  deterministic  test  pattern  application  to 
both  control  and  data  lines 

d.  scan-set,  supports  deterministic  test  pattern  application  to  both  control  and 
data  lines 

e.  test  pattern  generation  with  signature  analysis,  supports  pseudorandomly  gen¬ 
erated  control  and  data  line  inputs 

f.  parity  generation/checking 

g.  on-line  comparison  of  duplicated  modules 

The  first  five  are  off-line  techniques,  implying  that  the  system  is  not  operational  at  the 
time  of  testing  and  the  test  patterns  supported  are  noted.  The  last  two  are  on-line,  or 
concurrent  to  operation,  techniques  which  require  very  special  consideration. 
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controllability,  the  ability  to  control  values  on  nets.  The  controllability  of  a  line  is  the 
probability  that  a  randomly  applied  input  vector  will  set  the  line  to  a  given  value. 

controllable  loop,  a  closed  circuit  of  controllable  nodes.  Controllable  nodes  have  inputs 
which  are  primary  inputs  or  primary  input  controllable.  Controllable  loops  cannot 
contain  entirely  combinational  logic. 

design  for  testability  (DFT).  One  of  the  approaches  used  to  reduce  testing  costs  is  to 
recognize  testing  difficulties  when  designing  the  system,  subsystem,  board,  or  chip  and 
incorporate  certain  features  to  facilitate  fault  detection  and  fault  isolation  into  the 
design.  Design  styles  that  result  in  testable  designs  are  collectively  grouped  under  the 
name  “design  for  testability.”  Testability  is  desirable  because  it  reduces  the  cost  of 
testing  and  it  improves  the  quality  of  the  test. 

fanout  node. 

a.  a  node  is  a  fanout  node  if  its  attribute  hw_module  is  set  to  one  of  fanout, 
copy,  null 

b.  a  node  is  a  fanout  node  if  its  attribute  Tnode_type  is  set  to  one  of  fanout, 
copy,  null 

Fanout  nodes  are  not  recommended.  ADAS  buses  should  be  used  to  show  connections 
from  one  source  to  multiple  destinations.  In  general,  TEA  will  give  unpredictable 
results  if  fanout  nodes  are  used. 

large  node,  identified  by  Thw_module  (number  of  gates)  and  Tstates  (number  of 
states). 


Size  =  (gates) 

If  Size  >  2*^=65536,  a  node  is  large. 

mean  time  to  test,  sum  of  the  mean  times  given  to  test  the  ambiguity  groups 

observability,  the  ability  to  observe  values  on  nets.  The  observability  of  a  line  is  the 
probability  that  a  randomly  applied  input  vector  will  sensitize  one  or  more  paths  from 
that  line  to  a  primary  output. 

output  observable  (00). 

A  node  is  Primary  Output  Observable  if  all  of  its  outports  are  primary  output  observ¬ 
able.  The  following  is  the  order  in  which  outport  X  is  checked  to  see  T  it  is  Primary 
Output  Observable; 
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a.  The  outport  Is  checked  for  successors.  If  there  are  no  successors,  outport  X  is 
not  00.  If  one  or  more  successors  exists,  it  keeps  on  checking. 

b.  The  outgoing  arc  is  checked  to  see  if  the  Tdft_io  is  set  to  PO.  PI  or  TPO.  If 
so.  outport  X  is  00.  If  not.  it  keeps  on  checking. 

c.  The  sink  node  Is  checked  to  see  if  it  belongs  to  another  board.  If  so.  outporr  X 
is  00.  If  not.  it  keeps  on  checking. 

d.  The  sink  node  is  checked  to  see  if  it  has  outports.  If  the  sink  node  has  no  out- 
ports,  outport  X  is  00.  If  the  sink  node  does  have  outports,  it  keeps  on 
checking. 

e.  The  sink  node  is  checked  to  see  if  it  has  been  checked  before.  If  it  has.  this  is 
a  loop  and  outport  X  is  not  00.  If  it  has  not  been  checked  before,  it  goes 
back  to  step  a,  using  the  sink  node  for  outport  X. 

f.  The  outgoing  arc  (that  goes  out  from  outport  X)  is  checked  to  see  if  the 
Tarc_type  is  set  to  clock.  If  it  is  not  set  to  clock,  (i.e.,  data  or  control)  it 
keeps  on  checking.  If  Tarc_type  =  clock,  outport  X  is  not  00. 

g.  If  one  of  the  following  is  true,  then  it  goes  to  step  f.  Otherwise,  outport  X  is 
not  00.  The  Tlogic_type  for  the  sink  node  is  set  to  combinational 

1.  The  Tnode_type  for  the  sink  node  is  set  to  scan  latch 

2.  The  Tnode_type  for  the  sink  node  is  set  to  bus  (or  the  sink  is  a  bus) 

3.  The  Tnode_type  for  the  sink  node  is  set  to  fanout 

4.  The  Tnode_type  for  the  sink  node  is  set  to  flip  flop 

5.  The  Tnode_type  for  the  sink  node  is  set  to  counter 

6.  The  Tnode_type  for  the  sink  node  is  set  to  shift  register 

h.  A  node  must  be  PIC  in  order  to  be  OO. 

primary  input  (PI)  or  primary  output  (PO). 

a.  an  arc  with  Tdft_io  labeled  as  PI/PO 

b.  an  arc  which  crosses  from  one  board  to  another 

primary  input  controllable  (PIC).  A  node  is  Primary  Input  Controllable  if  all  of  its 
inports  are  PIC.  The  following  is  the  order  in  which  node  X  is  checked  to  see  if  it  is 
Primary  Input  Controllable: 

a.  A  node  port  is  NOT  PIC  if  the  inport  has  no  sources. 

b.  The  incoming  arc  is  checked  to  see  if  the  Tdft_io  is  set  to  PO,  PI  or  TPO.  If 
so,  inport  X  is  PIC.  If  not.  it  keeps  on  checking. 

c.  The  source  node  is  checked  to  see  if  it  comes  from  another  board.  If  so.  inport 
X  is  PIC.  If  not,  it  keeps  on  checking. 
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d.  The  source  node  is  checked  to  see  if  it  has  inports.  If  it  has  no  inports,  inport 
X  is  PIC.  If  the  source  node  does  have  inports,  it  keeps  on  checking. 

e.  The  source  node  is  checked  to  see  if  it  has  been  checked  before.  If  it  has.  this 
is  a  loop  and  inport  X  is  not  PIC.  If  it  has  not  been  checked  before,  it  goes 
back  to  step  a.  using  the  source  node  for  inport  X. 

f.  The  incoming  arc  (that  comes  into  inport  X)  is  checked  to  see  if  the 
Tarc_type  is  set  to  clock.  If  it  is  not  set  to  clock,  (ie,  data  or  control)  it  keeps 
on  checking.  If  Tarc_type  =  clock,  inport  X  is  not  PIC. 

g.  If  one  of  the  following  is  true,  then  it  goes  to  step  f.  Otherwise,  inport  X  is  not 
PIC. 

1.  The  Tlogic_type  for  the  source  node  is  set  to  combinational 

2.  The  Tnode_type  for  the  source  node  is  set  to  scan  latch 

3.  The  Tnode_type  for  the  source  node  is  set  to  bus  (or  the  source  is  a 
bus) 

4.  The  Tnode_type  for  the  source  node  is  set  to  fan  out 

sequential  node,  a  node  that  has  not  been  identified  as  combinational.  A  combina¬ 
tional  node  has  its  Tlogic_type  set  to  comb,  comb_logic,  combinational.  A  node  with 
no  Tlogic_type  value  is  sequential. 

test  patterns,  the  set  of  input  stimuli  used  to  verify  the  operation  of  a  system.  These 
patterns  can  be  generated  deterministically  or  pseudorandomly.  Some  systems  are 
better  tested  with  vectors  generated  one  way  over  the  other.  Typically,  only  patterns 
applied  to  data  inputs  are  generated  pseudorandomly. 

test  point  (TPO).  an  arc  with  Tdft_io  labeled  as  test  point,  test_point_output, 
test_pt_output,  tp,  tpo 

testability,  a  design  characteristic  which  allows  the  unit’s  status  (operable,  inoperable, 
or  degraded)  and  the  fault  locations  within  the  unit  to  be  confidently  determined  in  a 
timely  fashion 
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5.2.  Index. 


Architecture  Design  and  Assessment  Sys¬ 
tem  (ADAS),  1-1,  1-2,  1-3,  1-4,  1-5,  2-1, 

2-5,  2-7,  2-8,  2-13,  2-14,  2-15,  2-16,  2-18, 

2-19,  2-20,  2-21,  2-22,  2-24,  2-27,  2-30, 

2-31,  2-32,  2-33,  2-35,  2-36,  2-43,  2-44, 

2-46,  2-53,  2-59,  2-61,  2-65,  2-66,  2-69, 

2-73,  2  74,  2-76,  3-31,  3-41,  3-52,  4-1, 

4- 2,  4-5,  5-2,  5-7 

ambiguity  group  (AG),  1-2,  1-3,  2-4,  2-5, 
2-9,  2-13,  2-14,  2-15,  2-16,  2-17,  2-19, 
2-20,  2-21,  2-22,  2-24,  2-33,  2-34,  2-43, 

2-44,  2-45,  2-46,  2-47,  2-48,  2-49,  2-50, 

2-53,  2-54,  2-59,  2-61,  2-63,  2-65,  2-66, 

2-68,  2-69,  2-71,  2-73,  2-74,  2-75,  2-76, 

2- 77,  2-79,  3-3,  3-12,  3-32,  3-36,  3-42, 

3- 43,  3-44,  3-45,  3-46,  3-47,  3-48,  3-49, 

3-50,  3-51,  4-2,  4-4,  4-6,  4-7,  4-10,  4-13, 

5- 1,  5-2,  5-7 

Automatic  Test  Equipment  (ATE),  1-2, 
2-5,  2-33,  3-36,  3-39,  5-7 

built-in  test  (BIT),  1-1,  1-2,  1-3,  1-5,  2-,l, 

2- 3,  2-4,  2-5,  2-6,  2-7,  2-8,  2-9,  2-11,  2- 
13,  2-14,  2-15,  2-16,  2-17,  2-19,  2-20,  2- 
21,  2-22,  2-23,  2-24,  2-27,  2-29,  2-30,  2- 
32,  2-33,  2-34,  2-36,  2-37,  2-41,  2-43,  2- 
44,  2-45,  2-53,  2-54,  2-59,  2-61,  2-63,  2- 
65,  2-66,  2-67,  2-69,  2-71,  2-73,  2-74,  2- 
76,  2-77,  3-2,  3-3,  3-32,  3-36,  3-37,  3-39, 

3- 41,  3-42,  3-43,  3-44,  3-45,  3-46,  3-48, 

3- 49,  3-50,  3-51,  3-52,  5-1,  5-7 

BIT  Overhead  Summary  (bit_cost),  4-2, 

4- 4,  4-6,  4-7,  4-9,  4-10,  4-11,  4-12,  4-13 
BIT  Placement  Recommendation  (place- 

bit),  2-34,  2-65,  2-66,  2-67,  2-69,  2-71, 

4-2,  4-4,  4-6,  4-7,  4-9,  4-10,  4-11,  4-12, 

4-13 

BIT  Recommendation  (brt),  2-3,  2-9,  2-13, 
2-14,  2-15,  2-16,  2-34,  2-43.  2-46,  2-49, 
2-50,  2-52,  2-53,  2-54,  2-61,  2-65,  4-2, 

4- 4,  4-6,  4-7,  4-9,  4-10,  4-11,  4-12,  4-13, 
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design  for  testability  (DFT),  1-1,  1-2,  1-3, 
2-1,  2-4,  2-7,  2-9,  2-11,  2-13,  2-14,  2-15, 
2-16,  2-24,  2-25,  2-26,  2-27,  2-28,  5-1, 

5-2,  5-7 

design  for  testability  guideline  checker 
(dft),  2-29,  2-30,  2-32,  2-33,  2-34,  2-35, 
2-36,  2-37,  2-39,  2-40,  2-41,  2-42,  2-45, 


2- 59,  2-65.  2-74,  2-77,  3-1,  3-2,  3-3,  3-4, 

3- 6,  3-7,  3-8.  3-9,  3-10,  3-11,  3-12,  3-13, 
3-14,  3-17,  3-22,  3-25,  3-27,  3-29,  3-31, 

3- 32,  .3-36,  3-38,  3-39,  4-2,  4-3,  4-4,  4-5, 

4- 6,  4-7,  4-8,  4-9,  4-10,  4-11,  4-12,  4-13 

ETM,  2-6,  2-11,  2-13,  2-44,  2-45,  2-54,  3- 
32,  3-33,  3-38,  3-40 

JTAG,  2-6,  2-11,  2-44,  2-45,  2-54,  3-32,  3- 
34,  3-35 

System  Summary  (compare),  2-4,  2-27,  2- 
34,  2-69,  2-73,  2-74,  2-76,  3-51,  3-52,  4- 
2,  4-4,  4-6,  4-7,  4-9,  4-10,  4-11,  4-12,  4 
13,  5-7 

VHSIC  Hardware  Description  Language 
(VHDL),  1-1,  1-4,  1-5,  2-3,  2-5,  2-7,  2- 
15,  2-16,  2-32,  2-33,  2-59,  2-65,  3-41,  3- 
52,  5-7 
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5.3.  List  of  Acronyms. 


Software  Design  Document 
Acronyms  for  TEA  System 


AGO 

ACST 

ADAS 

ADS 

ADSD 

AG 

AJD 

AVI 

ATE 

BIT 

CA 

CAD 

CDSR 

CO 

COM 

COTR 

CDR 

CDRL 

CDSR 

CFSR 

CIDS 

CM 

CMP 

CPFF 

CRISD 

CSC 

CSCI 

CSDM 

CSOM 

CWBS 

DAC 

DAL/ID 

DAO 

DAR 

DBS 

DFT 

DID 


Administrative  Contracting  Officer 
Advanced  CAD/E  lor  Systems  Testability 
Architecture  Design  and  Assessment  System 
Automated  Data  System 
Automated  Data  System  Document 
Ambiguity  Group 

Analysis  and  Justifiv^ation  Document 

ADAS/VHDL  Interface 

Automatic  Test  Equipment 

Built-in  Test 

Configuration  Audit 

Computer-aided  Design 

Center  for  Digital  Systems  Research 

Contracting  Officer  (or  Commanding  Officer) 

Computer  Operation  Manual 

Contracting  Officer’s  Technical  Representative 

Critical  Design  Review 

Contract  Data  Requirements  List 

Center  for  Digital  System  Research 

Contract  Funds  Status  Report 

Critical  Item  Development  Specification 

Configuration  Management 

Configuration  Management  Plan 

Cost  Plus  Fixed  Fee 

Computer  Resources  Integrated  Support  Manual 

Compute."  Software  Component 

Computer  Software  Configuration  Item 

Computer  Software  Diagr  jstic  Manual 

Computer  System  Operator’s  Manual 

Contract  Work  Breakdown  Structure 

Days  After  Contract  Signed 

Data  Accession  List/Internal  Data 

Days  After  Option 

Defense  Acquisition  Regulations 

Data  Base  Specification 

Design  for  Testability 

Data  Item  Descriptions 
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DoD 

DoDISS 

DRD 

EDR 

ETM 

EGA 

ED 

EER 

EQR 

GFS 

HWCI 

INC 

IV& V 

JLC 

JTAG 

LLCSC 

LRU 

MCCS 

MN 

OM 

PGA 

PCO 

PDR 

PI 

PIDS 

PMM 

PP/APC 

PS 

PSR 

RTI 

SDD 

SDDD 

SDF 

SDL 

SDP 

SDR 

SOM 

SOW 

SQEP 

SRR 

SSSRD 

SSA 

SSPM 

SSR 


Department  of  Defense 

Department  of  Defense  Index  of  Specifications  and  Standards 

Data  Requirements  Document 

Evaluation  and  Demonstration  Report 

Element  Test  and  Maintenance 

Functional  Configuration  Audit 

Functional  Description 

Funds  Expenditure  Report 

Formal  Qualification  Review 

Government-F urnished  Software 

Hardware  Configuration  Item 

Incrementally  Funded  Contract 

Independent  Verification  &  Validation 

Joint  Logistics  Commanders 

Joint  Test  Action  Group 

Low  Level  Computer  Software  Component 

Line  Replaceable  Unit 

Mission  Critical  Computer  System 

Maintenance  Node 

Operator’s  Manual 

Physical  Configuration  Audit 

Procuring  Contracting  Officer 

Preliminary  Design  Review 

VHSIC  Interoperability 

Prime  Item  Development  Specification 

Program  Maintenance  Manual 

Project  Planning/Actual  Project  Chart 

Program  Specification 

Project  Status  Report 

Research  Triangle  Institute 

Software  Design  Document 

Software  Detailed  Design  Document 

Software  Development  File 

Software  Development  Library 

Software  Development  Plan 

System  Design  Review 

System  Operation  Manual 

Statement  Of  Work 

Software  Quality  Evaluation  Plan 

System  Requirements  Review 

System  Specification  and  Software  Requirements  Document 
Software  Support  Agency 
Software  Standards  and  Procedures  Manuals 
Software  Specification  Review 
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SSS  System  Subsystem  Specification 

STD  Software  Test  Description 

STP  Software  Test  Plan 

STPR  Software  Test  Procedure 

STR  Software  Test  Report 

SSUM  Software  System  User's  Manual 

SWCI  Software  Configuration  Item 

TAR  Test  Analysis  Report 

TEA  Test  Engineer’s  Assistant 

TEAS  Test  Engineer’s  Assistant  System 

TCO  Termination  Contracting  Officer 

TCU  Test  Control  Unit 

TIP  Technology  Insertion  Plan 

TISSS  Tester  Independent  Support  Software  System 

TLCSC  Top  Level  Computer  Software  Component 

TM  Test  and  Maintenance 

TP  Test  Plan 

TRR  Test  Readiness  Review 

UDF  Unit  Development  Folder 

UM  User’s  Manual 

USAF  United  States  Air  Force 

USN  United  States  Navy 

VDD  Version  Description  Document 

VHDL  VHSIC  Hardware  Description  Language 

VHSIC  Very  High  Speed  Integrated  Circuit 

VSC  VHSIC  Silicon  Compiler 

WBS  Work  Breakdown  Structure 

ag_name  TEA  Ambiguity  Group  Names 

bit_cost  TEA  BIT  Overhead  Summary 

brt  TEA  BIT  Recommendation 

compare  TEA  System  Summary 

dft  TEA  Design  for  Testability  Guideline  Checker 

help  TEA  On-Line  User  Support  System 

log_file  TEA  Report  Generation/Access 

placebit  TEA  BIT  Placement  Recommendation 
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Appendix  A 

Quick  DFT  Guideline  Reference 


Gl-01  Guideline:  Use  flip-flops,  counters,  and  shift  registers  with  a  Preset/Clear 
capability. 

Gl-02  Guideline:  Make  Preset/Clear  a  primary  input  or  primary  input  controll¬ 
able. 

Gl-03  Guideline:  Make  Dselect  of  multiplexors  a  primary  input  or  primary  input 
controllable. 

Gl-04  Guideline:  Vlake  Tristate  Control  a  primary  input  or  primary  input  con¬ 
trollable. 

Gl-05  Guideline:  Make  Enable/Hold  of  microprocessors  a  primary  input  or  pri¬ 
mary  input  controllable. 

Gl-06  Guideline:  Make  Chip  Select  (CS),  Address  Latch  Enable  (ALE),  Read,  and 
Write  of  memories  primary  inputs  or  primary  input  controllable. 

Gl-07  Guideline:  Make  Control  Access  of  any  bus  structure  a  primary  input  or 
primary  input  controllable. 

Gl-08  Guideline:  Make  buried  (i.e.,  not  primary  input  or  primary  input  controll¬ 
able)  control  lines  of  the  types  Preset/Clear;  Dselect  of  multiplexors;  Tristate  Control; 
Enable/Hold  of  microprocessors;  CS,  .:ALE,  Read,  and  Write  of  memories;  and  Control 
Access  of  bus  structures  primary  outputs. 

Gl-09  Guideline:  Make  the  output  of  all  logic  redundant  nodes  a  primary  output. 

Gl-10  Guideline:  Make  the  trunk  section  of  high  fanout  nodes  or  junctions  a  pri¬ 
mary  output. 

Gl-11  Guideline:  Terminate  all  unused  device  inputs  and  tristatable  outputs. 

Gl-12  Guideline:  Keep  analog  and  digital  circuits  physically  apart. 

Gl-13  Guideline:  Make  analog  lines  used  as  input  to  digital  data  acquisition  cir¬ 
cuits  a  primary  output, 

Gl-14  Guideline:  Avoid  asynchronous  logic. 

Gl-15  Guideline:  Avoid  uncontrollable  feedback. 

Gl-16  Guideline:  .\void  one-shots  as  delay  elements. 

G2-01  Guideline:  Make  all  on-board  clocks  a  primary  input  or  primary  input  con¬ 
trollable. 

G2-02  Guideline:  Avoid  fanout  greater  than  5. 

G2-03  Guideline:  Break  up  long  counter  chains  greater  than  8  bits  with  logic  that 
contains  primary  inputs  or  primary  input  controllable  lines. 

G2-04  Guideline:  Avoid  mixed  logic  families  on  the  same  board  unless  all  I/O  is 
compatible  in  logic  levels  and  rise  and  fall  times. 

G2-05  Guideline:  Limit  chip  fanout  at  test  points  to  one  less  than  the  specified 
maximum. 
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G2-06  Guideline:  Provide  the  refresh  circuitry  for  DRAMs  on  the  same  board  as 
the  RAM. 
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Appendix  B 


Alternative  BIT  Technique  Implementations 
Cui  rently  not  Supported  by  TEA 


TEA  supports  one  implementation  of  each  of  seven  board  level  built-in  test  techniques, 
designed  to  achieve  fault  detection  and/or  fault  isolation  to  a  particular  set  of  chips. 
This  appendix  is  designed  to  show  a  few  alternative  implementations  of  some  of  these 
techniques.  These  alternatives  .ARE  NOT  currently  supported  by  TE.V. 

.A  single  example  is  used  throughout  this  Appendix  to  illustrate  the  TE.A  techniques. 
Figure  3-1.5  shows  a  simple  system  consisting  of  three  undetermined  size  (number  of 
chips')  ambiguity  groups  (AG)  which  are  highly  interconnected.  Each  .AG  is  connected 
to  both  of  the  others.  Each  AG  accepts  input  from  the  board  edge  and  delivers  output 
to  the  board  edge.  This  example  does  not  show  any  special  AGs.  but  any  of  the  .AGs 
could  be  considered  special.  Simple  one-line  interconnections  are  shown  for  the  pur¬ 
poses  of  illustration. 

Continuous  Test  Point  Monitoring 

Figures  B-1  through  B-5  show  alternatives  of  this  technique  as  applied  to  the  example 
board  shown  in  Figure  3-15. 

The  implementation  shown  in  Figure  B-1  allows  the  outputs  of  test  points  to  be  read 
into  and  out  of  a  scan-set  register  so  that  the  results  can  be  serialized  for  analysis. 

Figure  B-2  shows  an  implementation  that  allows  for  self  generation  of  input  stimulus. 
Test  points  are  monitored  externally. 

A  combination  of  the  previous  two  options  are  shown  in  F’gure  B-3.  Input  stimulus  is 
generated  on  board  and  test  point  output  is  latched. 

An  alternative  to  the  last  option  allows  for  latching  both  the  input  stimulus  and  out¬ 
put  responses.  A  maintenance  node  is  shown  as  a  reminder  that  to  interface  to  a  sub¬ 
system  test  strategy  all  inputs  and  outputs  should  be  handled  through  a  maintenance 
node.  This  is  shown  in  Figure  B-4. 

This  continuous  test  point  monitoring  alternative  implementation  allows  for  both  pseu¬ 
dorandom  stimulus  for  data  lines  and  deterministic  stimulus  for  control  lines  and  also 
for  latching  of  the  test  point  output  data.  Figure  B-5  shows  this  most  complete 
option. 

Test  Point  Monitoring  with  Data  Compression 

Figure  B-6  shows  an  alternative  of  this  technique  as  applied  to  the  example  board 
shown  in  Figure  3-15.  Fanout  as  well  as  feedback  paths  are  broken  with  appropriate 
test  pattern  generation  capability  so  that  faults  are  better  isolated  to  ambiguity 
groups. 

Test  Pattern  Generation  with  Data  Compression 

Figures  B-7  through  B-10  show  alternatives  of  this  technique  as  applied  to  the  example 
board  shown  in  Figure  3-15. 

The  implementation  shown  in  Figure  B-7  uses  built-in  logic  block  observers  (BILBOs) 
instead  of  testing-switches  (TSWITCHes)  to  provide  the  input  and  compress  the  out¬ 
put. 
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Figure  B-1.  BIT  technique  1-b:  Test  point  monitoring  -  continuous 

(cycle  by  cycle) 
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Figure  B-2.  BIT  technique  1-c:  Test  point  monitoring  -  continuous 

(cycle  by  cycle) 
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Figure  B-3.  BIT  technique  1-d:  Test  point  monitoring  -  continuous 

(cycle  by  cycle) 
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Figure  B-4.  BIT  technique  1-e:  Test  point  monitoring  -  continuous 

(cycle  by  cycle) 
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Figure  B-5.  BIT  technique  1-f:  Test  point  monitoring  -  continuous 

(cycle  by  cycle) 
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Figure  B-6.  BIT  technique  2-b:  Test  point  monitoring  -  data  compression 
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Figure  B-7,  BIT  technique  5-b:  Test  pattern  generation  and  response 
compression  using  “BILBO”  modules  distributed  over  the  board 


Figure  B-8  shows  a  higher  overhead  alternative.  This  technique  keeps  lines  from  different 
sources  isolated  from  each  other  for  better  fault  isolation  capability.  Data  and  control  isola¬ 
tion  should  also  be  maintained.  A  maintenance  node  is  shown  as  a  reminder  that  every  board 
should  have  this  monitoring  and  interface  capability. 

Only  data  lines  are  intercepted  by  BILBOs  in  the  implementation  of  test  pattern  generation 
with  data  compression  shown  in  Figure  B-9.  This  results  in  lower  overhead  than  what  is 
experienced  in  the  implemented  version. 

Only  data  lines  are  intercepted  by  TSWlTCHes  in  the  implementation  of  test  pattern  genera¬ 
tion  with  data  compression  shown  in  Figure  B-10.  This  results  in  lower  overhead  than  what 
is  experienced  in  the  implemented  version. 
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Figure  B-8.  BIT  technique  5-c:  Test  pattern  generation  and  response 
compression  using  “Testing  Switch”  modules  -  control  and  data  are 

kept  separate 
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Figure  B-9.  BIT  technique  5-d:  Test  pattern  and  response  compression 
using  “BILBO”  modules  distributed  over  the  board  -  no  BILBO  for 

control  lines 
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Figure  B-10.  BIT  technique  5d:  Test  pattern  generation  and  response 
compression  using  “Test  Switch’’  modules  distributed  over  the  board  - 
no  “Testing  Switch”  for  control  lines 
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Appendix  C 

TEA  BIT  Module  Specifications 


TEA  provides  a  library  of  built-in  test  support  modules.  Included  in  this  library,  the 
user  receives 

a.  an  application  note  describing  the  function  of  the  module  along  with  an  exam¬ 
ple  implementation  and  notes  on  using  the  module  in  a  testing  situation 

b.  an  ADAS  template  to  use  when  adding  nodes  representing  BIT  support 
modules  into  a  graph 

c.  a  VHDL,  version  7.2,  structural  and/or  behavioral  description  of  the  module 

d.  a  gate  level  description  of  the  model  entered  in  CADAT  (product  of  HHB- 
Systems  of  Mahwah,  NJ)  format 

The  BIT  Overhead  Summary  (Paragraph  2.7.3)  and  BIT  Placement  Recommendation 
(Paragraph  2.7.4)  tools  use  the  library  to  pick  out  modules  to  support  the  BIT  tech¬ 
nique  chosen  by  the  user. 


List  of  Modules  Included  in  the  TEA  BIT  Module  Library 

.Mi  VHDL  models  can  be  find  in  subdirectories  off  [..src] 

BIT  Modules  with  CADAT  descriptions  in  [...cadat.versionl.bit] 
Structural  models  listed  before  behavioral  models 


Name 

ADAS 

Template 

Name 

VHDL 

Model 

Name 

CADAT 

File 

Name 

Notes 

Built-in  Logic 

BILBO 

bilbo  ent 

bilbo. ckt 

supports  test 

Block  Observer 

bilbo  arch 

bilbo. dsl 

pattern  genera- 

(BILBO) 

bilbo  beh 

bilbol.dsl 

tion  and  signa¬ 
ture  analysis 

Pseudorandom 

Test  Pattern 

Generator 
(External 
Exclusive-or  Im¬ 
plementation) 

TPG 

tpg_ext_ent 

tpg_ext_str 

tpg_ext_beh 

tpgl.ckt  tpgl.dsl 

supports  TEA 

BIT  techniques 

Pseudorandom 

Test  Pattern 

Generator  (Inter¬ 
nal  Exclusive-or 
Implementation) 

IEO_TPG 

tpg  int  ent 
tpg  int  str 
tpg_int_beh 

tpg2.ckt  tpg2.dsl 

not  used  au¬ 
tomatically  by 

any  TEA  BIT 
technique 

Scan-set 

SCAN 

ssbitent 

ss_bit_arch 

ss_bit_beh 

scanset.ckt 

scanset.dsl 

scanseta.dsl 

supports  several 
TEA  BIT  tech¬ 
niques 

Testing-Switch 

TSVVITCH 

test  switch  ent 
test_switch_str 
test  switch  beh 

switch. ckt 
switch  1. dsl 
switch2.dsl 

supports  gen  sa 
BIT  technique 
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BIT  Module  with  CADAT  description  in  [...cadat.version2.maint_node] 

No  behavioral  model  available 


Name 

ADAS 

Template 

Name 

VHDL 

Model 

Name 

CADAT 

File 

Name 

Notes 

Maintenance 

Node 

Maintenance 

Node  main  node  ent 
main_node_str 

mn.ckt  mn.dsl 

supports  subsys¬ 
tem  to  board 
testing  communi¬ 
cations  (mainly 
for  controlling 

the  BIT  modules 
on  the  board) 

Version  2  BIT  Modules  with  CADAT  descriptions  in  [...cadat.version2.bit] 

Only  structural  models  are  available 

Name  ADAS  VHDL  CADAT  Notes 

Template  Model  File 

Name  Name  Name 

BILBO 

BILB0v2 

bilbo_ent_ver2 

bilbo_arch_ver2 

bilbo. ckt 
bilbo.dsl 

interfaces  to  ex¬ 
ample  mainte¬ 

nance  node 

Pseudorandom 
Test  Pattern 

Generator 
(External 
Exclusive-or  Im¬ 
plementation) 

TPGv2 

tpg_ext_ent_ver2 

tpg_ext_arch_ver2 

tpgl.ckt  tpgl.dsl 

interfaces  to  e,x- 
ample  mainte¬ 

nance  node 

Pseudorandom 
Test  Pattern 

Generator  (Inter¬ 
nal  Exclusive-or 
Implementation) 

IE0_TPGv2  tpg_int_ent_ver2 
tpg_int_arch_ver2 

tpg2.ckt  tpg2.dsl 

interfaces  to  ex¬ 
ample  mainte¬ 

nance  node 

Scan-set 

SCANv2 

ss_bit_ent_ver2 
ss_b  i  t_arc  h_ver2 

scanset.ckt 

scanset.dsl 

interfaces  to  e.x- 
ample  mainte¬ 

nance  node 

Version  2  BIT  Module  with  CADAT  descriptions  in  [...cadat.version2.switch] 

Only  structural  model  is  available 

Name  ADAS  VHDL  CADAT  Notes 

Template  Model  File 

Name  Name  Name 

Testing-Switch 

TSWITCHv2 

test_switch  ent  ver2 
test_switch_arch_ver2 

mn.ckt  mn.dsl 

interfaces  to  ex¬ 
ample  mainte- 

nance  node 
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BIT  Modules  -with  VHDL  descriptions  in  [...src.specialj 

No  CAD  AT  files  available 


Name 

-ADAS 

Template 

Name 

VHDL 

Model 

Name 

C.ADAT 

File 

Name 

Notes 

8-bit  Equal  Com¬ 
parator 

COMP.ARE 

comp. entity 
comp,  parts 

NA 

supports  com¬ 
pare  BIT  tech¬ 
nique 

9-bit  Parity  Gen¬ 
erator  Checker 

P.ARITY 

parity. entity 
parity. parts 

NA 

supports  parity 
BIT  technique 

MUX2 

MUX2 

mux2  by_l6.entity 
mux2  by_16. behave 

NA 

2  sets  of  16  lines 
input 

NrUX4 

MUX4 

mux4_by_16. entity 
mux4  by_16. behave 

NA 

4  sets  of  16  lines 
input 

MUX2x8 

MUX2x8 

mux2_by_8. entity 
mux2_by_8. behave 

NA 

2  sets  of  8  lines 
input 

MUX4x8 

iVIUX4x8 

mux4  by_8. entity 
mux4  by_8. behave 

NA 

4  sets  of  8  lines 
input 

Ones 

ONES 

ones.entity 
ones. behave 

NA 

16  lines  of 

constant-valued 
high  output 

Zeros 

ZEROS 

zeros. entity 
zeros. behave 

NA 

16  lines  of 

constant-valued 
low  output 

NA;  Not  Available 
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Appendix  D 


ADAS-related  Information 


PART  I 


ADAS  Data  Base  File  Format 

This  part  defines  a  new  .\DAS  data  base  file  format  which  supports  changes  for  this 
contract  and  other  enhancements  being  made  concurrently  as  part  of  .ADAS  develop¬ 
ment. 

Each  ADAS  graph  is  stored  in  a  graph  data  base  file  which  contains  all  the  information 
about  the  graph  and  its  components.  Eight  different  types  of  graph  components  exist: 
nodes,  arcs,  buses,  partitions,  junctions,  inports,  outports,  and  biports.  Buses,  junc¬ 
tions,  and  biports  exist  only  in  hardware  graphs. 

A  template  data  base  file  is  associated  with  each  graph  data  base  file  and  contains 
templates  defining  the  characteristics  of  graph  components  present  in  the  correspond¬ 
ing  graph  data  base  file.  These  templates  are  used  in  adding  new  instances  of  graph 
components  to  a  graph. 

A  filename  extension  identifies  an  ADAS  data  base  file  as  either 

a.  a  hardware  graph  data  base  file  (".hwg"), 

b.  a  hardware  template  data  base  file  (".hwt"), 

c.  a  software  graph  data  base  file  (".swg"),  or 

d.  a  software  template  data  base  file  (".swt"). 

Each  variation  of  the  ADAS  data  base  file  has  the  same  format.  Information  in  the 
files  is  interpreted  differently  depending  on  the  variety.  ADAS  graph  and  template 
data  base  files  are  ASCII  text  files.  The  ADAS  data  base  routines  interpret  these  files 
as  consisting  of  records  terminated  by  carriage  returns  (<CR>).  No  special  character 
is  used  to  delimit  fields  within  these  records  except  in  cases  where  delimiters  are  expli¬ 
citly  mentioned.  A  record  field  may  belong  to  one  of  the  following  types: 

a.  string  —  an  ASCII  string  of  arbitrary  length; 

b.  Strings  —  an  alphanumeric  string  of  arbitrary  length,  terminated  by  a  dollar 
sign  ("$"):  e.g.,  "newnodeS"; 

c.  decimal  —  an  integer  represented  by  an  arbitrarily  long  string  of  decimal 
digits:  e.g.,  "101"; 

d.  B26  —  a  two-digit  base  26  integer  represented  by  using  lower  case  letters  of 
the  alphabet  (a  =  0,  b  =  1,  ...,  z  =  25).  Fields  of  type  B26  can  represent 
integers  in  the  range  [0.,67.5]  ([aa..zz]).  For  example,  the  value  "dx"  for  a  field 
of  type  B26  represents  the  integer  value  101: 

d  (=  3)  *  26  -1-  X  (=  23)  =  101. 
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An  ADAS  data  base  file  consists  of: 

a.  a  header  section, 

b.  the  graph  attribute  list, 

c.  a  node  section  containing  two  or  more  records  for  each  node  in  the  graph. 

d.  a  bus  section  containing  two  or  more  records  for  each  bus  in  the  graph. 

e.  an  arc  section  containing  two  records  for  each  arc  in  the  graph,  and 

f.  a  partition  section  containing  two  records  for  each  partition  in  the  graph. 

The  header  section  contains  eight  records: 

a.  a  record  with  the  following  fields  delimited  by  spaces: 

1.  the  keyword  "adasdb_new," 

2.  the  number  of  nodes  in  the  graph  (decimal), 

3.  the  number  of  arcs  in  the  graph  (decimal), 

4.  the  number  of  buses  in  the  graph  (decimal), 

o.  the  number  of  partitions  in  the  graph  (decimal); 

b.  the  template  search  path  for  the  graph  (string); 

c.  the  graph  attribute  definition  list; 

d.  the  node  attribute  definition  list; 

e.  the  bus  attribute  definition  list; 

f.  the  arc  attribute  definition  list; 

g.  the  partition  attribute  definition  list; 

h.  the  inport  attribute  definition  list; 

i.  the  outport  attribute  definition  list; 

j.  the  biport  attribute  definition  list; 

k.  a  record  containing  only  the  string  "%end%,"  marking  the  end  of  the  header. 

Each  attribute  definition  list  has  the  following  fields: 

a.  a  one-letter  code  identifying  the  type  of  the  object: 

1.  "G"  —  graph, 

2  —  node, 

3.  "B"  —  bus, 

4.  "A"  —  arc, 

5.  "P"  —  partition, 

6.  "I"  —  inport, 
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7.  "O"  — outport, 

8.  "D"  —  biport; 

b.  the  total  number  of  attributes  present  for  objects  of  that  type  (B26); 

c.  the  ADAS  internal  data  base  name  (attribute  ID)  for  each  attribute  of  that 
object  type  (stringS). 

An  attribute  definition  list  defines  the  set  of  ADAS  attributes  for  its  object  type  writ¬ 
ten  to  the  data  base  file.  This  list  may  or  may  not  contain  the  full  set  of  ADAS  attri¬ 
butes.  An  attribute  list  for  a  given  object  has  entries  only  for  the  attributes  appearing 
in  the  attribute  definition  list  for  its  type. 

Each  attribute  list  is  a  record  consisting  of  the  following  fields: 

a.  a  one-letter  code  identifying  the  object  type  ("G,"  "N,"  "B,"  "A,"  "P,"  "I," 
”0,"  or  "D"), 

b.  two  fields  for  each  attribute  appearing  in  the  attribute  definition  list  for  that 
object  type: 

1.  a  one-letter  modifiability  code: 

a)  "M"  —  modifiable, 

b)  "P"  —  modifiable  only  by  ADAS  programs  (not  by  the  user  with 
the  edit  command), 

c)  "N"  —  not  modifiable, 

d)  "U"  —  unused  status; 

2.  the  value  of  the  attribute  (stringS). 

For  each  node  in  the  graph  there  are  two  or  more  records: 

a.  one  record  containing: 

1.  the  node’s  (x,  y)  location  on  the  graph  grid  (B26,  B26), 

2.  the  number  of  inports  on  the  node  (B26), 

3.  the  number  of  outports  on  the  node  (B26), 

4.  the  number  of  biports  on  the  node  (B26), 

.5.  the  node’s  name  (string$); 

b.  a  node  attribute  list; 

c.  an  inport  attribute  list  for  each  of  the  node’s  inports; 

d.  an  outport  attribute  list  for  each  of  the  node’s  outports; 

e.  a  biport  attribute  list  for  each  of  the  node’s  biports. 
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For  each  bus  in  the  graph  there  are  two  or  more  records: 

a.  a  record  containing 

1.  the  number  of  junctions  on  the  bus  (B26), 

2.  the  bus  name  (string$); 

b.  a  bus  attribute  list; 

c.  a  record  for  each  junction  on  the  bus  containing  the  junction's  location  (B26, 
B26). 

For  each  arc  in  the  graph  are  two  records: 

a.  a  record  containing: 

1.  the  arc’s  name  (stringS), 

2.  the  (x,  y)  coordinates  of  its  source  {B26,  B26), 

3.  the  number  of  its  source  port  or  connection  (B26), 

4.  the  type  of  its  source  port  (B26), 

5.  the  (x,  y)  coordinates  of  its  sink  (B26,  B26), 

6.  the  number  of  its  sink  port  or  connection  (B26), 

7.  the  type  of  its  sink  port  (B26); 

b.  an  arc  attribute  list. 

For  each  partition  in  the  graph  are  two  records: 

a.  the  partition’s  name  (stringS),  and 

b.  a  partition  attribute  list. 
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PART  n 


ADAS  Data  Base  Routines 


FOREWORD 

This  part  has  been  adapted  from  a  UNIX  manual  page  entry  for  the  .\DAS  data  base  routines.  Its 
intended  audience  is  programmers  writing  software  that  uses  the  ADAS  data  base.  The  routines 
described  herein  constitute  the  interface  to  the  ADAS  data  base  for  all  .ADAS  related  tools.  Pro¬ 
grams  using  these  routines  must  include  the  file  “adasdb.h". 

CONTENTS 

Page  No. 


Graph  Components . II-6 

Hierarchical  Structure . II-6 

Purpose  of  the  ADASDB  Library . II-6 

Graph  Data  Bases . II-6 

Viewing  the  Graph  Hierarchy . II-7 

The  Current  Graph  and  Current  Data  Base . II-7 

Error  Handling . II-7 

Debugging  Facilities . II-8 

Conventions  Used  in  This  Document . II-8 

Definition  of  .ADASDB  Routines . II-8 

Initializing  and  Terminating  Graphs . II-8 

DBGraphInit() . II-8 

DBUseGraph() . 11-9 

DBTermGraph() . II-9 

DBIsGraphInit() . II-9 

DBGetCurrGraph() . II-9 

DBIsHWGraphO . II-9 

Updating  the  External  Data  Base . II-9 

DBVVriteDb() . II-9 

Handling  Subgraphs . II-9 

DBSubgraphInit() . 11-10 

DBFreeSubgraphQ . II-IO 

DBIsExpanded() . II- 10 

Traversing  the  Data  Base  Hierarchy . II-IO 

DBPushDb() . II-IO 

DBPopDb() . II-ll 

DBGetCurrGraphLevel() . 11-11 

DBGetCDBFileName() . 11-11 

Accessing  Graph  Elements  Through  Connectivity . II-ll 

DBViewGraph() . II- U 

DBGetSourceNode() . 1I-1‘2 

DBGetSourcc() . 11-12 

DBGetSinkNodeO . II- 12 

DBGetSink() . 11-13 

DBGetInputArc() . 11-13 

DBGetOutputArc() . 11-13 
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DBGetNode,Ajc() . 11-14 

DBGer.BusArc( ) . 11-14 

DBGet,ParentNode() . 11-14 

DBGetBusParentNode() . 11-14 

DBGetParentArc() . 11-15 

Accessing  Graph  Elements  in  the  Current  Data  Base . 11-15 

DBGetNodeByLoc() . 11-15 

DBGetNodeByNamel) . 11-15 

DBGetArcByName() . 11-15 

DBGetBusByName() . 11-15 

DBGetPartitionByName() . •. . 11-15 

DBGet  JunctionByLoc() . 11-16 
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GRAPH  COMPONENTS 


The  .ADAS  system  uses  directed  graphs  to  model  hardware  and  software  systems.  These  graphs 
consist  of  collections  of  nodes  (representing  hardware  processors  or  software  modules)  that  are  con¬ 
nected  by  arcs  (representing  data  flow  paths  between  nodes).  Hardware  graphs  can  also  include 
buses  which  may  be  attached  to  nodes  via  arcs. 

Node  ports  provide  places  on  a  node  where  arcs  may  attach  and  .are  referred  to  by  numbers.  If  a 
node  has  N  input  ports,  they  are  numbered  0  through  N-1.  Softw-are  graph  nodes  can  have  inports 
and  outports,  while  hardware  graph  nodes  can  also  have  biports.  Only  one  arc  may  be  attached  to 
a  particular  port.  Bus  junctions  provide  the  connection  points  for  arcs  on  buses.  Any  number  of 
arcs  may  be  attached  to  each  junction. 

Each  element  in  a  graph  has  a  number  of  attributes  that  characterize  it.  When  an  element  is 
created,  the  initial  values  for  these  attributes  are  taken  from  a  template  used  to  generate  the  ele¬ 
ment. 

HIERARCHICAL  STRUCTURE 

ADAS  graphs  are  hierarchical:  they  are  organized  in  a  tree  structure  consisting  of  one  or  more  lev¬ 
els.  The  single  graph  at  the  top  of  this  tree  structure  is  called  the  root. 

.An  individual  node  on  one  level  may  be  expanded  into  an  entire  subgraph  on  the  next  level.  In 
keeping  with  tree  structure  terminology,  a  node  that  has  a  subgraph  is  an  internal  node;  other¬ 
wise,  it  is  a  leaf  node.  An  internal  node  is  the  parent  of  all  nodes  in  its  subgraph. 

Special  nodes  called  graph  ports  represent  the  connections  of  a  subgraph  with  nodes  connected  to 
its  parent  node.  There  is  a  one-to-one  mapping  between  graph  ports  of  a  subgraph  and  node  ports 
of  the  subgraph’s  parent  node. 

PURPOSE  OF  THE  ADASDB  LIBRARY 

The  ADASDB  routines  provide  application  programs  with  the  ability  to  manipulate  the  elements 
of  a  graph,  expand  nodes  into  subgraphs,  and  traverse  graph  hierarchies. 

The  ADASDB  routines  embody  the  principles  of  information  hiding.  Application  programs  mani¬ 
pulate  graphs  and  graph  elements  indirectly  through  the  ADASDB  routines  and  are  not  required 
to  know  the  makeup  of  various  internal  data  structures  and  file  formats  used  to  represent  graphs. 

ADASDB  supports  two  different  logical  views  of  graphs.  Applications  programs  may  look  at  a 
graph  in  terms  of  its  connectivity,  or  in  terms  of  a  grid  with  nodes  at  the  grid  intersections. 

Finally,  ADASDB  provides  attribute  independence.  Applications  programs  can  only  deal  with 
relevant  graph  component  attributes  and  ignore  the  rest.  Also,  adding  new  attributes  is  done 
transparently  and  requires  only  recompilation  of  the  ADASDB  library,  followed  by  relinking  of  the 
applications  programs. 

GRAPH  DATA  BASES 

ADAS  graphs  are  defined  by  graph  data  bases.  These  data  bases  are  normally  stored  as  disk  files. 
When  an  application  program  wants  to  access  a  graph,  it  invokes  an  ADASDB  routine  that  reads 
the  data  base  from  the  disk  file  and  creates  an  internal  (in-memory)  version.  -All  subsequent 
operations  are  performed  on  this  internal  version  of  the  data  base.  Since  this  internal  data  base 
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exists  only  while  the  program  executes,  it  must  be  written  back  to  the  disk  file  if  modifications 
made  to  it  are  to  be  preserved. 

VIEWING  THE  GRAPH  HIERARCHY 

The  root  and  each  subgraph  of  a  graph  hierarchy  are  kept  on  disk  as  separate  data  base  fi'es. 
This  separation  is  maintained  internally;  when  a  node  is  expanded,  its  subgraph  is  kept  as  a 
separate  data  base.  These  data  bases  are  arranged  in  a  hierarchy  that  mirrors  the  subgraph 
hierarchy.  A  set  of  ADASDB  routines  is  provided  for  traversing  this  data  base  hierarchy  depth- 
first  in  an  orderly  manner. 

Since  the  data  bases  in  a  graph  hierarchy  are  kept  separately,  they  can  be  manipulated  individu¬ 
ally.  even  when  a  graph  is  partially  or  fully  expanded.  This  approach  is  useful  when  editing 
graphs  where  the  connections  between  subgraphs  at  the  same  level  are  not  needed. 

An  expanded  graph  can  also  be  viewed  as  a  hierarchy  with  a  single  graph  at  each  level,  formed  by 
joining  all  the  subgraphs  at  that  level.  This  approach  is  useful  in  graph  analysis  when  it  is  desir¬ 
able  to  view  all  subgraphs  at  a  particular  level  as  a  single  graph. 

THE  CURRENT  GRAPH  AND  CURRENT  DATA  BASE 

Because  there  can  be  multiple  internal  data  bases  within  a  given  graph  hierarchy  and  because 
many  ADASDB  routines  are  designed  to  operate  on  a  particular  data  base  (e.g.,  most  of  the  ele¬ 
ment  retrieval  routines),  ADASDB  maintains  a  current  data  base.  Data  base-specific  operations 
are  performed  on  this  current  data  base.  The  DBPushDb  and  DBPopDb  routines  change  the 
current  data  base,  allowing  the  data  base  hierarchy  to  be  traversed. 

ADASDB  also  can  simultaneously  handle  multiple  root  graphs  and  multiple  graph  hierarchies. 
The  DBGraphInit  routine  initializes  new  root  graphs,  and  the  DBUseGraph  routine  provides  a  way 
of  specifying  which  graph  to  work  on  currently. 

If  multiple  graph  hierarchies  are  simultaneously  in  the  memory,  each  hierarchy  keeps  track  of  its 
own  current  data  base.  When  switching  to  a  different  hierarchy,  the  current  data  base  becomes 
that  of  the  current  hierarchy. 

ERROR  HANDLING 

If  an  ADASDB  routine  encounters  an  error  condition,  it  returns  immediately  without  performing 
its  intended  action.  In  addition,  it  sets  a  global  error  flag  dberrno  with  an  error  code  that  indi¬ 
cates  the  nature  of  the  error.  The  meaning  of  an  error  code  in  the  context  of  a  particular  routine 
is  described  in  that  routine’s  definition.  A  list  of  error  codes  is  provided  at  the  end  of  this  docu¬ 
ment.  All  error  codes  are  negative  integers. 

Once  dberrno  is  set,  it  is  not  reset  unless  another  error  occurs  subsequently. 

Aside  from  setting  dberrno,  ADASDB  routines  have  other  ways  of  indicating  errors,  depending  on 
what  kind  of  routine  they  are. 

If  a  routine  is  a  procedure  (i.e.,  does  not  return  a  value),  then  it  generally  returns  an  integer  com¬ 
pletion  code.  A  negative  code  indicates  an  error.  A  zero  code  indicates  normal  completion. 

On  the  other  hand,  if  a  routine  is  a  function  (i.e.,  does  return  a  value),  then  it  generally  indicates 
an  error  by  returning  a  value  that  is  out  of  its  normal  range.  For  instance,  a  routine  that 
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normally  returns  a  character  string  will  return  a  null  pointer  (NULL)  on  error. 

DEBUGGING  FACILITIES 

The  ADASDB  routines  provide  several  debugging  facilities  for  aiding  installation  and  maintenance. 

When  the  ADASDB  subroutine  library  is  compiled  with  the  DEBUG  option  (this  should  be  done  in 
the  ADASDB  makefile),  there  is  a  trace  facility  and  an  assertion  facility. 

The  trace  facility  prints  useful  information  about  what  the  data  base  routines  are  doing.  Tracing 
is  turned  on  by  setting  the  external  integer  dbtrace  to  1  and  is  disabled  by  setting  dbtrace  to  0. 
Tracing  may  be  turned  on  or  off  at  any  point  during  a  program’s  execution. 

The  assertion  facility  is  not  program  controlled.  It  checks  certain  conditions  within  the  data  base 
routines  that  are  assumed  to  be  true.  If  an  assumption  is  not  met,  the  program  is  forced  to  exit, 
printing  out  the  name  and  line  number  of  the  ADASDB  source  file  where  the  problem  occurred. 
This  message  should  be  reported  to  the  ADASDB  maintenance  person  who  can  then  track  down 
the  problem. 

Lint,  the  C  program  verifier,  should  be  used  when  installing  the  ADASDB  routines  in  a  program  to 
insure  that  procedure  parameters  are  correct  in  type  and  number.  A  lint  library  for  the  ADASDB 
has  been  created  and  can  be  used  as  described  above  in  the  synopsis  section. 

CONVENTIONS  USED  IN  THIS  DOCUMENT 

All  upper-case  keywords  in  this  document  are  symbolic  constants.  These  constants  are  defined  in 
the  header  file  adasdb.h. 

Italicized  words  are  either  new  or  important  terms,  or  the  names  of  ADASDB  routines  or  their 
parameters. 

DEFINITION  OF  ADASDB  ROUTINES 

The  remainder  of  this  document  consists  of  brief  definitions  of  the  routines  that  comprise  the 
ADASDB  library. 

INITIALIZING  AND  TERMINATING  GRAPHS 

int  DBGraphlnit(dbfile) 

char  *dbfile; 

DBGraphInit  initializes  a  graph,  returning  a  descriptor  for  the  new  graph.  This  descriptor  is  a 
small  non-negative  integer  like  a  UNIX  file  descriptor.  The  root  data  base  of  the  new  graph  is  the 
graph’s  default  current  data  base.  The  root  data  base  is  initialized.  If  dbfiU  exists,  it  is  read  into 
the  root  data  base. 

Returns  graph  descriptor  (small  non-negative  integer)  on  normal  completion,  (l)  XINIT  if  there  are 
no  more  unused  graph  descriptors,  (2)  XACCESS  if  it  couldn’t  open  external  data  base.  (3) 
XFORMAT  ifit  couldn’t  read  external  data  base,  (4)  XEOF  if  a  premature  end-of-file  is  encoun¬ 
tered  while  reading  external  data  base,  and  (.5)  XMEMORY  if  ran  out  of  memory. 

NOTE:  this  routine  MUST  be  called  before  any  data  base  operations  are  performed  on  this  graph. 
See  also  DBUseGraph(). 
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DBUseGraph(gd) 

int  gci: 


DBUseGraph  makes  graph  hierarchy  denoted  by  the  graph  descriptor  ijd  the  current  graph.  The 
descriptor  gd  must  be  one  returned  by  the  routine  DBGraphlnit. 

Assumes  gd  is  a  valid  graph  descriptor. 

The  previous  graph  descriptor  is  returned. 


DBTermGraph() 

DBTermGraph  deletes  all  nodes  and  arcs  in  the  root  of  the  current  graph  and  makes  the  graph 
available  for  reinitialization  by  DBGraphInit.  Since  DBTermGraph  frees  all  memory  occupied  by 
the  terminated  graph,  graphs  that  are  no  longer  being  used  should  be  terminated  to  reduce  a 
program's  memory  requirements. 

No  return  code. 


int  DBIsGraphlnit(gcl) 

int  gd; 

DBIsGraphInit  returns  a  nonzero  value  when  the  graph  with  descriptor  gd  is  initialized  and  other¬ 
wise,  a  zero. 


int  DBGetCurrGraph() 

DBGetCurrGraph  returns  the  graph  descriptor  of  the  current  graph. 


boolean  DBIsHWGraph() 

DBIsHWGraph  returns  TRUE  if  the  current  graph  is  a  hardware  graph,  and  F.ALSE  otherwise. 

UPDATING  THE  EXTERNAL  DATA  BASE 

DBWriteDb(dbfile) 

char  *dbfile; 

DBWriteDb  writes  the  contents  of  the  current  data  base  to  the  file  dbfile.  This  is  the  only  routine 
that  actually  modifies  an  external  data  base. 

If  dbfile  already  exists,  it  will  be  overwritten. 

Returns  XACCESS  if  dbfile  cannot  be  opened  for  writing. 

HANDLING  SUBGRAPHS 

The  following  routines  manipulate  subgraphs.  A  node  is  expanded  if  its  class  is  INTERN.AL  (see 
DBGelNodeClanaO)  and  it  currently  has  an  internal  subgraph  data  base  associated  with  it. 
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DBSubgraphInit(n,  dbfile,  newdb) 

nodetype  n: 
char  *dbiile: 
boolean  *newdb: 

DBSub graph Init  creates  a  new  subgraph  for  internal  node  n.  VIemory  is  allocated  for  the  new  data 
base,  then  a  new  subgraph  is  created  by  adding  one  graph  in/ out  port  for  each  in/out  port  of  node 
n.  Node  n  is  made  the  "parent"  of  all  the  nodes  in  the  new  subgraph  (see  DBGetParentNodei }). 
DBSub graphinit  sets  newdb  to  TRUE  if  dbfile  did  not  already  exist,  and  to  F.^LSE  otherwise. 

If  data  base  file  dbfile  exists,  it  is  read  into  the  internal  subgraph  data  base. 

Returns  XACCESS  if  dbfile  exists  but  couldn’t  be  opened.  XFORMAT  if  dbfile  exists  but  couldn't 
be  read,  XEOF  if  premature  EOF  encountered  while  reading  dbfile.  XMEMORY  if  we  ran  out  of 
memory. 

Assumes  n  is  in  the  current  data  base.  .Assumes  class  of  n  is  INTERNAL.  .Assumes  n  is  not 
already  e.xpanded.  Assumes  we  are  not  trying  to  expand  past  graph  level  MAXDEPTH. 


DBFreeSubgraph(ii) 

nodetype  n; 

DBFreeSubgraph  frees  the  space  occupied  by  the  internal  subgraph  data  base  of  node  n.  This  rou¬ 
tine  has  no  effect  on  the  corresponding  external  data  bases. 

Assumes  n  is  in  the  current  data  base,  is  class  INTERNAL,  and  is  currently  expanded.  .Assumes 
no  nodes  in  the  subgraph  are  currently  expanded. 

No  return  code. 


boolean  DBIsExpanded(n) 

nodetype  n; 

DBIsExpanded  returns  TRUE  if  the  subgraph  of  node  n  is  currently  expanded,  and  false  otherwise. 
Assumes  node  n  is  internal. 

TRAVERSING  THE  DATA  BASE  HIERARCHY 

The  following  routines  change  the  current  data  base.  .A  stack  of  data  bases  allows  the  graph 
hierarchy  to  be  traversed  depth-first  in  an  orderly  manner. 


DBPushDb(n) 

nodetype  n; 

DBPushDb  pushes  the  current  data  base  onto  the  data  base  stack  and  makes  the  subgraph  data 
base  of  node  n  the  new  current  data  base. 

Assumes  n  is  an  internal  node  in  the  current  data  base,  and  it  is  currently  expanded. 

No  return  code. 
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DBPopDb() 


DBPopDb  pops  the  top  data  base  from  the  data  base  stack  and  makes  it  the  new  current  data 
base. 

-Assumes  current  data  base  is  a  subgraph  (i.e..  graph  level  is  >  0). 

No  return  code. 


int  DBGetCurrGraphLevel() 

DBGetCurrGraphLevel  returns  the  level  within  the  graph  hierarchy  ot"  the  current  data  base,  i.e.. 
the  current  data  base  stack  level. 


char  •DBGetCDBFileNameO 

DBGetCDBFileName  returns  the  name  of  the  ADAS  data  base  file  associated  with  the  current 
data  base. 


ACCESSING  GRAPH  ELEMENTS  THROUGH  CONNECTIVITY 

Graph  connectivity  can  be  viewed  in  one  of  two  ways.  The  normal  (default)  view  looks  at  node, 
arc.  and  bus  connections  within  a  single  data  base.  The  alternate  view  looks  at  the  connections 
that  e.xist  between  subgraphs  at  the  lowest  level  of  the  graph  hierarchy  only  when  the  graph  is 
flattened  (see  DBVieu'Graph()).  This  alternate  view  makes  all  subgraphs  at  the  lowest  level  appear 
to  be  a  single  graph  and  allows  the  inter-data  base  connections  to  be  traversed. 


int  DBViewGraph(view) 
int  view; 

DBViewGraph  sets  the  view  of  the  graph  hierarchy  that  will  be  used  for  connectivity  purposes.  If 
the  view  is  NORMAL,  the  graph  hierarchy  is  viewed  as  a  collection  of  subgraphs  that  may  be 
separately  manipulated.  This  is  the  default  view. 

If  the  view  is  FLAT,  the  entire  hierarchy  is  (conceptually)  flattened  into  a  single  graph  consisting 
of  all  leaf  nodes  in  the  hierarchy. 

Returns  previous  view. 

Only  connectivity  routines,  e.g.,  DBGetNextN'fde,  DBGetOnlputArc,  DBGetSink.Xode.  are  directly 
affected  by  the  graph  view.  When  the  flat  view  is  used,  the  DBSetFirstNode  DBGetXeitXode  rou¬ 
tines  may  be  used  to  step  through  all  nodes  in  the  flattened  graph,  and  the 
DBGetSource/  DBSinkNode  and  DBGetlnputf  DBOutputArc  routines  automatically  follow  inter¬ 
subgraph  and  inter-level  connections. 

After  DBViewGraph  is  called  initially,  subsequent  calls  are  quite  cheap  in  terms  of  the  amount  of 
work  the  routine  has  to  do. 
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NOTE:  Because  of  the  way  DBVitwGraph  is  implemented,  changes  to  graph  connectivity  should 
never  be  made  after  DBViewGraph  is  called.  Changes  include  adding/ deleting  nodes  or  arcs, 
expanding/unexpanding  subgraphs,  etc. 

NOTE:  DBViewGraph  does  not  actually  e.xpand  subgraphs,  it  only  flattens  subgraphs  that  are 
already  expanded.  Expansion  must  be  done  explicitly  by  the  user  program  before  DBViewGraph  is 
called  for  the  first  time.  If  a  node's  class  is  INTERN.\L,  but  the  node  is  not  expanded,  it  is  con¬ 
sidered  a  leaf  node  for  connectivity  purposes  and  is  included  in  the  flattened  graph. 


DBGetSourceNode(a,  np,  portp) 

arctype  a; 
nodetype  *np; 
int  *portp; 

DBGetSourceNode  sets  the  pointer  np  .o  point  to  the  source  node  for  arc  a.  The  integer  pointed 
to  by  portp  is  set  to  the  outport  where  a  is  attached.  If  the  graph  is  flattened  (see  DBView- 
Graph()),  inter-data  base  connectivity  is  used;  otherwise,  normal  connectivity  is  used. 

No  return  code. 

.Although  calls  to  DBGetSourceNode  are  still  supported,  this  routine  has  been  superceded  by 
DBGetSource.  New  code  should  use  DBGetSource  instead  of  DBGetSourceNode. 


DBGetSource(a,  bp,  junction,  np,  conn,  ioflag) 

arctype  a; 
bustype  *bp; 
int  ‘junction; 
nodetype  *np; 
int  ‘conn; 
int  ‘ioflag; 

DBGetSource  returns  the  source  of  arc  a.  If  the  source  is  a  bus,  DBGetSource  sets  the  pointer  bp 
to  point  to  the  source  bus  and  sets  junction  to  the  junction  index;  conn  to  the  connection  number 
of  the  arc;  and  np  to  NULL.  If  the  source  is  a  node,  np  is  set  to  point  to  the  source  node:  conn  is 
set  to  the  source  port  number;  ioflag  is  set  to  the  type  of  the  port  to  which  the  arc  is  connected 
(OUT  or  BI);  and  bp  is  set  to  NULL. 

Note,  there  is  no  notion  of  "source"  or  "sink"  for  the  connection  of  an  arc  to  a  junction  or  node 
biport.  A  bus  is  considered  the  source  of  an  arc  only  if  the  other  end  of  the  arc  is  attached  to  a 
node  inport.  If  an  arc  is  attached  to  biports  on  both  ends,  the  assignment  of  source  and  sink 
depends  on  which  node  is  chosen  as  the  source  at  the  time  the  arc  !s  created.  DBGetSource  and 
DBGetSink  are  guaranteed  not  to  return  the  same  node. 


DBGetSinkNode(a,  np,  portp) 

arctype  a; 
nodetype  ‘np; 
int  ‘portp; 

DBGelSinkNode  sets  the  node  pointed  to  by  np  to  the  Jink  node  for  arc  a.  The  integer  pointed  !o 
by  portp  is  set  to  the  inport  where  the  a  is  attached. 
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If  the  graph  is  flattened  (see  DBVitwGraphi )),  inter-data  base  connectivity  is  used;  otherwise.  ;ior- 
mal  connectivity  is  used. 

No  return  code. 

.\ithough  calls  to  DBGelSink  are  still  supported,  this  routine  has  been  superceded  by  OBGctSink. 
.New  code  should  use  DBGetSink  instead  of  DBGetSink. 


DBGetSink(a,  bp,  junction,  np,  conn,  ioflag) 

arctype  a: 
bustype  *bp; 
int  ‘junction; 
nodetype  *np; 
int  ‘conn; 
int  ‘ioflag; 

DBGetSink  returns  the  sink  of  arc  a.  If  the  sink  is  a  bus,  it  sets  the  pointer  bp  to  point  to  the  bus. 
sets  junction  to  the  junction  index,  conn  to  the  connection  number,  and  np  to  .Nl,rLL.  If  the  sink 
is  a  node,  it  sets  the  pointer  np  to  the  node,  conn  to  the  port  index,  ioflag  to  the  port  type,  and  bp 
to  NULL. 

Note  no  notion  of  “source"  or  "sink"  exists  for  the  connection  of  an  arc  to  a  junction  or  node 
biport.  A  bus  is  considered  the  sink  of  an  arc  if  the  other  end  of  the  arc  is  attached  to  a  node  out- 
port  or  biport.  If  an  arc  is  attached  to  biports  on  both  ends,  the  assignment  of  source  and  sink 
depends  on  which  node  was  specified  as  the  source  when  the  arc  was  created.  DjjGetSouree.  and 
DBGetSink  are  guaranteed  not  to  return  the  same  node. 


DBGetInputArc(n,  port,  ap) 
nodetype  n; 
int  port: 
arctype  *ap; 

DBGetlnputArc  sets  the  arc  pointed  to  by  ap  to  the  input  arc  associated  with  inport  port  on  node 
n. 


If  the  graph  is  flattened  (see  DBViewGraph()),  inter-data  base  connectivity  is  used;  otherwise,  nor¬ 
mal  connectivity  is  used. 

Assumes  port  is  a  valid  port  number  for  node  n:  assumes  an  arc  is  connected  at  port. 

No  return  code. 

.■\lthough  calls  to  DBGetlnputArc  are  still  supported,  this  routine  has  been  superceded  by  DBGet- 
NodeArc.  New  code  should  use  DBGetNodeArc  instead  of  DBGetlnputArc. 


DBGetOutnutArc(n,  port,  ap) 

nodetype  n; 
int  port; 
arctype  ‘ap; 
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DBGetOutputArc  sets  the  arc  pointed  to  by  ap  to  the  output  arc  associated  with  outport  port  on 
node  n. 

If  the  graph  is  flattened  (see  DBViewGraphI )),  mter-data  base  connectivity  is  used:  otherwise,  nor¬ 
mal  connectivity  is  used. 

Assumes  port  is  a  valid  port  number  for  node  n;  assumes  there  is  an  arc  connected  at  port. 

No  return  code. 

Although  calls  to  DBGttOntputArc  .are  still  supported,  this  routine  has  been  superceded  by 
DBGetNodeArc.  New  code  should  use  DBGetNoHeAre  instead  of  DBGetOutputArc. 


DBGetNodeArc(n,  port,  ioflag,  ap) 

nodetype  n: 
int  port; 
int  ioflag; 
arciype  *ap; 

DBGetNodeArc  sets  the  pointer  ap  to  point  to  the  arc  associated  with  port  number  port  of  the 
port  type  specified  by  ioflag  (inport,  outport,  or  biport)  on  node  n. 


DBGetBusArc(b,  junction,  conn,  ap) 

buslype  b; 
int  junction; 
int  conn; 
arctype  *ap; 

DBGetBusArc  sets  the  pointer  ap  to  point  to  the  arc  connected  at  connection  number  conn  on 
junction  junction  of  bus  6. 


DBGetParentNode(n,  parent) 
nodetype  n; 
nodetype  ‘parent; 

DBGetParentNode  sets  the  node  pointed  to  by  parent  to  the  parent  node  of  node  n,  or  NULL  if  n 
has  no  parent,  which  only  happens  if  n  is  in  the  root  data  base. 

No  return  code. 


DBG  BusParentNode(b,  parent) 

bustyj  j  b; 
nodetype  ‘parent; 

DBGetParentNode  sets  the  node  pointed  to  by  parent  to  the  parent  node  of  bus  b.  or  Nl'LL  if  b 
has  no  parent,  which  only  happens  if  6  is  in  the  root  data  base. 

No  return  code. 
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DBGetParentArc(a,  parent) 

arctype  a,  ‘parent; 

DBGetParentArc  sets  the  arc  pointed  to  by  parent  to  the  parent  arc  of  a.  or  NULL  if  a  has  no 
parent,  which  only  happens  if  a  is  in  the  root  data  base. 

No  return  code. 

ACCESSING  GRAPH  ELEMENTS  IN  THE  CURRENT  DATA  BASE 

DBGetNodeByLoc(x,  y,  np) 

int  X,  y; 
nodetype  *np; 

DBGetNodeByLoc  sets  the  node  pointed  to  by  np  to  the  node  at  graph  location  {x.y)  in  the  current 
data  base. 

Assumes  location  is  in  bounds. 

Returns  XNOTFOUND  if  there  is  no  node  at  location  {x,y). 


DBGetNodeByName(name,  np) 
char  ‘name; 
nodetype  ‘np; 

DBGetNodeByName  sets  the  pointer  np  to  point  to  node  name  in  the  current  data  base.  Returns 
XNOTFOUND  if  there  is  no  such  node  in  the  current  data  base. 


DBGetArcByName(name,  ap) 

char  ‘name; 
arctype  ‘ap; 

DBG etArcBy Name  sets  the  arc  pointer  ap  to  point  to  arc  name  in  the  current  data  base.  Returns 
XNOTFOUND  if  there  is  no  such  arc  in  the  current  data  base. 


DBGetBusByName(nanie,  bp) 
char  ‘name; 
buslype  ‘bp; 

DBGetBusByName  sets  the  pointer  bp  to  point  to  bus  name  in  the  current  data  base.  Returns 
XNOTFOUND  if  there  is  no  such  bus  in  the  current  data  base. 


DBGetPartitionByName(name,  pp) 

char  ‘name; 
parttype  pp; 

DBGetPartitionByName  sets  the  pointer  pp  to  point  to  the  partition  named  name  in  the  current 
data  base.  Returns  XNOTFOLIND  if  there  is  no  such  partition  in  the  current  data  base. 
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DBGetJuiictionByLoc(x,  y,  bp,  jp) 

int  x; 
int  y; 

bustype  *bp; 
int  *jp 

DBGetJunctionByLoc  sets  the  pointer  6p  to  point  to  the  bus  and  the  integer  pointed  to  by  jp  to 
the  index  of  the  junction  at  coordinates  {x,  y). 


DBSetFirstNode() 

DBSetFiratNode  resets  the  node  list  of  the  current  data  base  (or  flattened  graph)  to  an  arbitrary 
first  node.  See  the  explanation  of  DBGetNextNode  for  more  detail. 

No  return  code. 


DBGetNextNode(np) 
nodetype  *np; 

DBGetNextNode,  when  used  in  conjunction  with  DBSetFiratNode  and  DBMoreNodes,  permits 
sequential  access  to  all  nodes  in  the  current  data  base.  A  call  to  DBSetFtrstNode  resets  a  node  list 
maintained  in  the  current  data  base.  Each  subsequent  call  to  DBGetNextNode  sets  the  node 
pointed  to  by  np  to  an  arbitrary  next  node  in  the  current  data  base  until  all  nodes  have  been 
retrieved.  DBMoreNodea  returns  TRUE  while  there  are  still  nodes  in  the  list. 

If  the  graph  view  is  FLAT  (see  DBViewGraph),  instead  of  using  the  node  list  of  the  current  data 
base,  DBSetFiratNode,  DBMoreNodea,  and  DBGetNextNode  operate  on  the  node  list  for  the  entire 
flattened  graph. 

Assumes  there  are  more  nodes  in  the  list  (see  DBMoreNodea). 

No  return  code. 


boolean  DBMoreNodes() 

DBMoreNodea  returns  TRUE  while  there  are  still  nodes  in  the  node  list  of  the  current  (or  flat¬ 
tened)  data  base.  See  DBGetNextNode. 


DBSetFirstArc() 

DBSetFiratBua  resets  the  arc  list  of  the  current  data  base  to  an  arbitrary  first  arc.  See  DBGetNex- 
tArc. 


DBGetNextArc(ap) 

arctype  *ap; 

DBGetNextArc,  when  used  in  conjunction  with  DBSetFiratArc  and  DBMoreArca.  permits  sequen¬ 
tial  access  to  all  arcs  in  the  current  data  base.  A  call  to  DBSetFir.atArc  resets  an  arc  list 
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maintained  in  the  current  data  base.  Each  subsequent  call  to  DBGetNextArc  sets  the  arc  pointed 
to  by  (ip  to  an  arbitrary  next  arc  in  the  current  data  base  until  all  arcs  have  been  retrieved. 
DBMoreArcs  returns  TRUE  while  there  are  still  arcs  in  the  list. 


boolean  DBMoreArcs() 

DBMoreArcs  returns  TRUE  while  there  are  still  arcs  in  the  arc  list  of  the  current  data  base.  See 
DBGetNextArc. 


DBSetFirstBus() 

DBSetFirstBue  resets  the  bus  list  of  the  current  data  base  to  an  arbitrary  first  bus.  See  DBGet- 
NextBus. 


DBGetNextBus(bp) 

bustype  *bp; 

DBGetNextBu.i,  when  used  in  conjunction  with  DBSetFirstBus  and  DBMoreBuses,  permits  sequen¬ 
tial  access  to  all  buses  in  the  current  data  base.  A  call  to  DBSetFirstBus  resets  a  bus  list  main¬ 
tained  in  the  current  data  base.  Each  subsequent  call  to  DBGetNextBus  sets  the  bus  pointed  to  by 
bp  to  an  arbitrary  next  bus  in  the  current  data  base  until  all  buses  have  been  retrieved.  DBMore- 
Buses  returns  TRUE  while  there  are  still  buses  in  the  list. 


boolean  DBMoreBuses() 

DBMoreBuses  returns  TRUE  while  there  are  still  buses  in  the  bus  list  of  the  current  data  base. 
See  DBGetNextBus. 


DBSetFirstPartition() 

DBSetFirstPartition  resets  the  partition  list  of  the  current  data  base  to  an  arbitrary  first  partition. 
See  DBGetNextPartition. 


DBGetNextPartition(pp) 

parttype  *pp; 

DBGetNextPartition.  when  used  in  conjunction  with  DBSetFirstPartition  and  DBMoreParlilions. 
permits  sequential  access  to  all  partitions  in  the  current  data  base.  A  call  to  DBSetFirstPartition 
resets  a  partition  list  maintained  in  the  current  data  base.  Each  subsequent  call  to  DBGet¬ 
NextPartition  sets  the  partition,  pointed  to  by  pp,  to  an  arbitrary  next  partition  in  the  current 
data  base  until  all  partitions  have  been  retrieved.  DBMorePartitions  returns  TRUE  while  there  are 
still  partitions  in  the  list. 
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boolean  DBMorePartitions() 

DBMoreArcs  returns  TRL^  wiiile  r.here  are  -still  partitions  in  the  partition  list  oi’  rhe  current  data 
base.  See  DBGetNextPartition. 


DBGetGraphPort(port,  ioflag,  np) 

int  port: 
int  ioflag; 
nodetype  *np; 

DBGetGraphPort  sets  the  node  pointed  to  by  np  to  the  graph  inport  or  outport  port  of  the  current 
data  base.  It  assumes  ioflag  is  either  IN  (for  graph  inport)  or  OUT  (for  graph  outport). 

Returns  XNOTFOUND  if  no  graph  port  port  is  found  in  the  current  data  base. 


DBGetGraphParent(np) 

nodetype  *np; 

DBGetGraphParent  sets  the  node  pointed  to  by  np  to  the  parent  node  of  the  current  subgraph. 

It  assumes  the  current  data  base  is  a  subgraph  (not  the  root  graph). 

No  return  code. 

ADDING  AND  DELETING  GRAPH  ELEMENTS 

When  a  graph  element  is  added  to  the  internal  data  base,  it  is  initialized  using  a  previously 
defined  template.  Initialization  fills  in  the  initial  attributes  of  the  graph  element  using  the  tem¬ 
plate  attributes.  These  templates  are  found  by  scanning  the  files  in  the  template  search  path  (see 
DBSetTSPathO). 

Graph  element  names  must  begin  with  a  letter,  contain  letters  and/or  digits,  and  be  no  longer 
than  ATTLEN  characters.  Routines  in  this  section  that  operate  on  node  ports  take  a  parameter 
called  ioflag.  This  flag  must  have  a  value  of  IN,  OUT,  or  BI,  indicating  whether  the  operation  is  to 
be  performed  on  an  inport,  outport,  or  biport. 


DBAddNode(x,  y,  template,  name,  np) 

int  X,  y; 

char  *template; 
char  *name; 
nodetype  *np; 

DBAddNode  adds  a  new  node  to  the  current  data  base  at  location  {x,y).  Inports  and  outports  are 
allocated  to  the  node  and  attributes  are  initialized  using  the  specifications  in  template.  Name  is 
the  name  given  to  the  node.  If  name  is  NULL,  template  is  used  as  the  node  name,  with  digits 
appended  as  needed  to  make  the  name  unique. 

Sets  the  pointer  np  to  point  to  the  new  node. 

Returns  (I)  XI/OCATION  if  location  (i.y)  is  already  occupied  by  another  node  or  is  out  of  bounds. 
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(2)  XACCESS  if  it  couldn’t  access  one  of  the  template  files  in  the  search  path.  (3)  XFORNLA.T  if  it 
couldn't  read  one  of  the  template  files  in  the  search  path,  (4)  XEOF  if  it  encountered  a  premature 
end-of-file  while  reading  a  template  file,  (5)  XNOTFOUND  if  template  was  not  found,  and  '(5) 
XNAJvIE  if  name  is  already  being  used  by  another  node  or  does  not  have  the  proper  format. 


DBAddlnport(n) 

nodetype  n; 

DBAddInport  adds  a  new  inport  to  node  n.  The  index  of  the  new  inport  will  be  one  greater  than 
the  highest  index  of  an  inport  currently  on  node  n,  or  will  be  zero  if  there  are  no  inports. 


DBAddOutport(n) 

nodetype  n; 

DBAddOutport  adds  a  new  outport  to  node  n.  The  index  of  the  new  outport  will  either  be  one 
greater  than  the  highest  index  of  an  outport  currently  on  node  n  or  zero  if  there  are  no  outports. 


DBAddBiport(n) 

nodetype  n; 

DBAddBiport  adds  a  new  biport  to  node  n.  The  index  of  the  new  biport  will  either  be  one  greater 
than  the  highest  index  of  an  biport  currently  on  node  n  or  zero  if  there  are  no  biports. 


DBReplicatePort(n,  count,  ioflag) 

nodetype  n; 
int  count; 
int  ioflag; 

DBReplicatePort  copies  the  single  port  of  type  ioflag  on  node  n  so  that  n  has  count  ports  of  that 
type.  It  is  used  to  create  node  templates  from  the  master  node  template. 


DBAddArc(src,  srcport,  srcflag,  sink,  sinkport,  sinkflag,  bus,  template,  name,  ap) 

nodetype  src; 
int  srcport; 
int  srcflag; 
nodetype  sink; 
int  sinkport; 
int  sinkflag; 
bustype  bus; 
char  ‘template; 
char  ‘name; 
arctype  ‘ap; 

DBAddArc  adds  a  new  arc  to  the  data  base,  connecting  it  to  its  source  and  sink.  If  src  is  not 
NULL,  it  is  the  source  node  of  the  arc;  otherwise,  bus  is  the  arc’s  source.  If  sink  is  not  NULL,  it  is 
the  sink  of  the  arc;  otherwise,  bus  is  the  arc’s  sink.  Obviously,  either  the  source  or  sink,  but  not 
both,  may  be  a  bus.  The  source  and  sink  ports  to  which  the  new  arc  is  connected  are  given  by 
srcport  and  sinkport.  If  the  source  or  sink  is  a  bus,  ■srcport  or  sinkport  gives  the  index  of  the 
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junction  to  which  the  arc  is  attached.  The  values  of  sreflag  and  sinkflag  indicate  the  types  of  the 
source  and  sink  ports.  Sreflag  can  be  OUT  for  an  outport.  or  BI  for  a  biport.  Sinkflag  can  be  IN 
for  an  inport,  or  BI  for  a  biport.  The  arc  template  named  template  is  used  to  initialize  the  new 
arc.  Name  is  the  name  given  to  the  arc.  If  name  is  null,  template  is  used  as  the  arc  name,  with 
digits  appended  as  needed  to  make  the  name  unique. 

Sets  the  pointer  ap  to  point  to  the  new  arc. 

Returns  (1)  XPORT  if  arcs  are  already  attached  at  sreport  or  sinkport,  (2)  XACCESS  if  it  couldn’t 
access  one  of  the  template  files  in  the  search  path,  (3)  XFORMAT  if  it  couldn’t  read  one  of  the 
template  files  in  the  search  path,  (4)  XEOF  if  it  encountered  premature  end-of-file  while  reading  a 
template  file,  (5)  XNOTFOUND  if  template  does  not  exist,  and  (6)  XNAVIE  if  name  is  already 
being  used  by  another  arc  or  does  not  have  the  proper  format. 


DBAddBus(template,  name,  bp) 
char  ‘template; 
char  ‘name; 
bustype  ‘bp; 

DBAddBns  adds  a  new  bus  to  the  current  data  base.  Attributes  are  initialized  using  the  specifica¬ 
tions  in  the  bus  template  named  template.  Name  is  the  name  given  to  the  bus.  If  name  is  NULL, 
template  is  used  as  the  bus  name,  with  digits  appended  as  needed  to  make  the  name  unique.  The 
new  bus  is  created  without  junctions.  The  pointer  bp  is  set  to  point  to  the  new  bus. 


DBAddPartition(name,  color,  niist,  ncount,  pp) 

char  ‘  name; 

char  ‘  color; 

char  ‘  niist; 

char  *  ncount; 

parttype  *pp; 

DBAddPartition  adds  a  partition  with  name  name  to  the  current  data  base.  The  new  partition’s 
partitionjcolor,  partilion_node_count,  and  partition_node_list  attributes  are  set  to  the  values 
color,  niist,  and  ncovnt.  Other  attributes  are  initialized  using  the  specifications  in  the  partition 
template  from  the  master  template  file.  The  pointer  pp  is  set  to  point  to  the  new  partition. 


DBAddJunction(b,  junction,  x,  y) 

bustype  b; 
int  junction; 
int  X,  y; 

DBAddJunction  adds  a  new  junction  to  bus  b.  The  junction  is  added  at  location  (i,  g)  with  the 
index  junction,  which  specifies  its  position  in  the  ordered  list  of  the  bus’s  junctions. 


DBAddNode2(tmpl,  x,  y,  np) 

nodetype  tmpl; 
int  X,  y; 
nodetype  *np; 
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DBAddNode2  adds  a  new  node  to  the  current,  data  base  at  location  [x.y).  Existing  node  Impl  is  the 
node  template  that  will  determine  the  initial  characteristics  of  the  new  node,  including  node  attri¬ 
butes  and  the  number  of  inports  and  outports.  .A.  unique  name  is  generated  for  the  new  node  by 
appending  one  or  two  digits  onto  the  name  of  node  tmpl.  The  node  pointed  to  by  up  is  set  ro  the 
new  node. 

Returns  XN'IEMORY  if  the  memory  runs  out  while  trying  to  allocate  space  for  this  node.  Returns 
XNAME  if  the  new  name  generated  exceeds  the  maximum  length. 

.Assumes  location  (x.y)  is  in  bounds  and  not  currently  occupied  by  another  node. 


DBAddArc2(tmpl,  src,  srcport,  srcflag,  sink,  sinkport,  sinkflag,  bus,  ap) 

arctype  tmpl; 
nodetype  src; 
int  srcport; 
int  srcflag; 
nodetype  sink; 
int  sinkport; 
int  sinkflag; 
bustype  bus; 
arctype  *ap; 

DBAddArcS  adds  a  new  arc  to  the  current  data  base,  src  and  srcport  will  be  the  source  node  and 
source  port  of  the  new  arc;  sink  and  sinkport  will  be  the  sink  node  and  port.  If  src  is  NULL.  6u.s  is 
the  source  of  the  arc  and  srcport  is  the  junction  on  the  bus  where  the  arc  is  attached.  If  sink  is 
NLTL,  bus  is  the  arc  sink  and  sinkport  is  the  junction.  Existing  arc  tmpt  is  used  to  initialize  the 
attributes  of  the  new  arc.  A  unique  name  is  generated  by  appending  one  or  two  digits  onto  the  arc 
name  of  ttnpt.  The  arc  pointed  to  by  ap  is  set  to  the  new  arc. 

Returns  XMEMORY  if  the  memory  runs  out  while  trying  to  allocate  space  for  a  new  arc  structure. 

Assumes  source  and  sink  nodes  are  in  current  data  base;  assumes  the  nodes  have  the  indicated 
ports  and  arcs  are  not  already  attached  there. 


DBAddBus2(tmpl,  bp) 

bustype  tmpl; 
bustype  *bp; 

DBAddBusS  adds  a  new  bus  to  the  current  data  base.  Attributes  are  initialized  using  the  specifi¬ 
cations  in  the  bus  template  hnpl.  The  name  of  the  new  bus  is  created  by  appending  digits  to  the 
template  name.  The  new  bus  is  created  without  having  junctions.  The  pointer  bp  is  set  to  point 
to  the  new  bus. 


DBDeleteNode(n) 

nodetype  n; 

DBDeletcNode  removes  the  node  n  and  its  associated  arcs  from  the  current  data  base. 
No  return  code. 
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OBDeleteInport(n,  inport) 

nodetype  n; 
int  inport; 

DBDeleteInport  deletes  the  inport  with  index  inport  from  node  n.  The  inport  is  removed  from 
position  inport,  and  inports  with  higher  indices  have  their  indices  decremented  by  one. 


DBDeleteOutport(n,  outport) 
nodetype  n; 
int  outport; 

DBDeieteOutport  deletes  the  outport  with  index  outport  from  node  n.  The  outport  is  removed 
from  position  outport,  and  outports  with  higher  indices  have  their  indices  decremented  by  one. 


DBDeleteBiport(n,  biport) 

nodetype  n; 
int  biport; 

DBDeleteBiport  deletes  the  biport  with  index  biport  from  node  n.  The  biport  is  removed  from 
position  biport,  and  biports  with  higher  indices  have  their  indices  decremented  by  one. 


DBDeleteArc(a) 
arctype  a; 

DBDeleteArc  disconnects  arc  a  from  the  source  and  sink  ports  where  it  is  attached,  then  removes  a 
from  the  data  base. 

No  return  code. 


DBDeleteBus(b) 

bustype  b; 

DBDeUuBua  removes  the  bus  b  and  any  arcs  attached  to  its  junctions  from  the  current  data  base. 


DBDeletePartition(p) 
parttype  p; 

DBDeletePartition  deletes  partition  p  from  the  current  data  base. 


DBDeleteJunction(bus,  junction) 

bustype  bus; 
int  junction; 

DBDeleteJunction  deletes  junction  junction  of  bus  bus.  .Junctions  in  the  bus  having  indices  higher 
than  junction  will  have  their  indices  decremented  by  one. 
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int  DBAddGPorts(tgd,  n,  tmpflag) 

int  tgd: 
nodetype  n; 
boolean  tmpflag; 

DBAddGPorts  adds  graph  port  nodes  corresponding  to  the  ports  of  node  n  to  the  current  sub¬ 
graph.  If  templates  are  needed  for  these  new  nodes,  they  are  added  to  the  template  data  base 
with  graph  descriptor  tgd,  and  tmpflag  is  set  to  TRUE. 
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GETTING  AND  SETTING  GRAPH  ELEMENT  NAMES 


Graph  elements  names  are  not  handled  like  other  attributes.  The  routines  in  this  section  are  used 
to  determine  and  modify  graph  element  names. 


char*  DBGetNodeName(ii) 

nodetype  n; 

DBGetNodeName  returns  the  name  of  node  n;  it  also  returns  a  pointer  to  a  static  buffer  that  is 
overwritten  each  time  the  routine  is  called,  so  the  user  should  make  a  copy  of  the  string,  should  it 
need  to  be  saved. 


DBRenaineNode(n,  name) 

nodetype  n; 
char  *name; 

DBRenameNode  changes  the  name  of  node  n  to  name. 

Returns  XNAME  if  name  is  not  valid  or  already  being  used  by  another  node. 


char*  DBGetArcName(a) 

arctype  a; 

DBGetAreName  returns  the  name  of  arc  a  and  returns  a  pointer  to  a  static  buffer  that  is  overwrit¬ 
ten  each  time  the  routine  is  called,  so  the  user  should  make  a  copy  of  the  string  if  it  needs  to  be 
saved. 


DBRenameArc(a,  name) 

arctype  a; 
char  *name; 

DBRenameArc  changes  the  name  of  arc  a  to  name. 

Returns  XNAME  if  name  is  not  valid  or  already  being  used  by  another  arc. 


char*  DBGetBusName(b) 

bustype  b; 

DBGelBusName  returns  the  name  of  bus  6;  returns  a  pointer  to  a  static  buffer  that  is  overwritten 
each  time  the  routine  is  called,  so  the  user  should  make  a  copy  of  the  string  if  it  needs  to  be  saved. 


DBRenameBus(b,  name) 

bustype  b; 
char  *name; 

DBRenameBus  changes  the  name  of  bus  6  to  name. 
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char*  DBGetPartitionName(p) 

paritype  p: 

DBGntPartitionName  returns  the  name  of  partition  p.  It  returns  a  pointer  to  a  static  buffer  that 
is  overwritten  each  time  the  routine  is  called,  so  the  user  should  make  a  copy  of  the  string  if  it 
needs  to  be  saved. 


DBRenamePartition(p,  name) 
parttype  *p; 
char  *name; 

DBRenamePartition  changes  the  name  of  partition  p  to  name. 

GETTING  AND  SETTING  GRAPH  ELEMENT  FLAG  VALUES 

Every  graph  element  is  equipped  with  a  general  purpose  flag  and  a  utility  bit  flag.  The  general 
purpose  flag  is  an  integer.  The  utility  flag  provides  eight  independent  boolean  flags,  numbered  0 
through  7.  Both  the  general  flag  and  the  utility  flags  are  provided  for  use  by  application  programs 
for  their  own  purposes.  These  flags  are  not  used  in  any  way  by  the  data  base  routines.  The  follow¬ 
ing  routines  are  used  to  get  and  set  values  for  these  flags. 


int  DBGetNodeFiag(n) 

nodetype  n;  . 

DBGetNodeFlag  returns  the  value  of  node  n’s  general  purpose  flag. 


DBSetNodeFlag(n,  val) 
nodetype  n; 
int  val; 

DBSetNodeFlag  sets  the  general  purpose  flag  of  node  n  to  val. 


boolean  DBGetUtilFlag(n,  flag) 

nodetype  n; 

Int  flag; 

DBGetUtilFlag  returns  the  value  of  node  ri’s  utility  bit  flag  flag. 


DBSetUtilFlag(n,  flag,  val) 

nodetype  n; 
int  flag; 
boolean  val; 

DBSetUlilFlag  sets  the  value  of  node  n’s  utility  bit  flag  flag  to  val. 


Appendix  D,  11-25 


int  DBGetArcFlag(a) 

arctype  a; 

DBGetArcFlag  returns  the  value  of  arc  a  s  general  purpose  flag. 


DBSetArcFIag(a,  val) 

arctype  a; 
int  val; 

DBStlArcFlag  sets  flag  of  arc  a  to  val. 


boleanDBGetArcUtilFlag(a,  flag) 
arctype  a; 
int  flag; 

DBGetArcUtilFlag  returns  the  value  of  arc  a’s  utility  bit  flag  flag. 


DBSetArcUtilFlag(a,  flag,  val) 

arctype  a; 
int  flag; 
boolean  val; 

DBSetAreUtilFlag  sets  the  value  of  arc  a’s  utility  bit  flag  flag  to  val. 


int  DBGetBusFlag(b) 

bustype  b; 

DBGetBusFlag  returns  the  value  of  bus  6’s  general  purpose  flag. 


DBS»»tBusFlag(b,  val) 
bustype  b; 
int  val; 

DBSetBn.sFlag  sets  the  general  purpose  flag  of  bus  6  to  val. 


boolean  DBGetBusUtilFIag(b,  flag) 

bustype  b; 
int  flag; 

DBGetBusUtilFlag  returns  the  value  of  bus  6’s  utility  bit  flag  flag. 
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DBSetBusUtiiFlag(b,  flag,  val) 

bustype  b; 
ini  flag; 
boolean  val; 

DBSetBusUtilFlag  sets  the  value  of  bus  6’s  utility  bit  flag  flag  to  val. 


int  DBGetPartitionFlag(p) 

parttype  p; 

DBGetPartitionFlag  returns  the  value  of  partition  p's  general  purpose  flag. 


^BSetPartitionFlag(p,  val) 

parttype  p; 
int  val; 

DBSetPartitionFlag  sets  the  general  purpose  flag  of  partition  p  to  val. 

boolean  DBGetPartUtilFlag(p,  flag) 

parttype  p; 
int  flag; 

DBGitPartUiUFlag  returns  the  value  of  partition  p’s  utility  bit  (lag  flag. 


DBSetPartUtilFlag(p,  flag,  val) 

parttype  p; 
int  flag; 
boolean  val; 

DBSelPartUtilFlag  sets  the  value  of  partition  p’s  utility  bit  flag  flag  to  val. 


int  DBGetPortFlag(n,  port,  ioflag) 

nodetype  n; 
int  port; 
int  ioflag; 

DBGetPortFlag  returns  the  value  of  the  general  purpose  flag  for  port  port  of  type  ioflag  on  node  n. 


DBSetPortFlag(n,  port,  ioflag,  val) 

nodetype  n; 
int  port; 
int  ioflag; 
int  val; 

DB.SetPortFlag  sets  the  value  of  the  general  purpose  flag  for  port  port  of  type  ioflag  on  node  n  to 
val. 
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boolean  DBGetPortUtiIFIag(n,  port,  ioflag,  flag) 

nodeiype  n: 
int  port: 
int  ioflag; 
int  flag; 

DBGetPortUtilFlag  returns  the  value  of  utility  bit  flag  flag  for  port  port  of  type  ioflag  on  node  n. 

DBSetPortUtilFlag(n,  port,  ioflag,  flag,  val) 

nodetype  n; 
int  port; 
int  ioflag; 
int  flag; 
boolean  val; 

DBSetPortUtilFlag  sets  the  value  of  utility  bit  flag  flag  for  port  port  of  type  ioflag  on  node  n  to  val. 

MISCELLANEOUS  OPERATIONS  ON  GRAPH  ELEMENTS 

Routines  in  this  section  that  operate  on  node  ports  and  graph  ports  take  a  parameter  called  ioflag. 
This  flag  must  have  a  value  of  either  IN,  OUT,  or  BI,  indicating  whether  the  operation  is  to  be 
performed  on  an  inport,  outport,  or  biport. 


DBMoveNod[e(n,  x,  y) 
nodetype  n; 
int  X,  y; 

DBMoveNode  moves  the  node  n  to  the  new  location  (x,y)  in  the  current  data  beise. 

Assumes  location  is  in  bounds  and  not  occupied  by  another  node.  It  assumes  node  n  is  in  the 
current  data  base. 


DBOetNodeLoc(n,  xp,  yp) 
nodetype  n; 
int  *xp,  ‘yp; 

DBGetNodeLoc  copies  the  (x,y)  coordinates  of  node  n  within  the  current  data  base  into  the 
integers  pointed  to  by  xp  and  yp. 


int  DBGetPortCount(n,  ioflag) 
nodetype  n; 
int  ioflag; 

DBGetPortCount  returns  the  number  of  inports,  outports,  or  biports  associated  with  node  n. 
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boolean  DBPortHasArc(n,  port,  ioflag) 

nodetype  n: 
int  port: 
int  ioflag; 

DBPortHasArc  returns  TRUE  if  there  is  an  arc  attached  at  inport,  outport,  or  biport  port  on  node 
n.  and  FALSE  if  not. 

.Assumes  port  is  a  valid  port  number  for  node  n. 


int  DBGetGraphPortCount(ioflag) 

int  ioflag; 

DBGetGraphPortCount  returns  the  number  of  graph  inports,  outports.  or  biports  in  the  current 
data  base. 


int  DBSetGraphPort(n,  port) 

nodetype  n; 
int  port; 

DBSetGraphPort  sets  the  graph  port  number  of  node  n  to  port.  Note  that  this  number  is  only 
meaningful  if  n  is  a  graph  port,  i.e.,  its  class  is  either  “graph_inport."  ‘'graph_outport."  or 
"graph_biport." 

Returns  XRANGE  if  port  is  less  than  zero  or  greater  than  MAXPORTS. 


int  DBGetGPortNuni(n) 
nodetype  n; 

DBGetGPortNUM  returns  the  graph  port  number  of  node  n.  Note  that  this  number  is  only  mean¬ 
ingful  if  n  is  a  graph  port,  i.e.,  its  class  is  either  "graphjnport,"  "graph_outport.''  or 
''graph_biport." 


boolean  DBIsInBounds(x,  y) 

int  X,  y; 

DBhInBounds  returns  TRUE  if  location  (x,  y)  is  in  the  bounds  of  the  graph  grid;  otherwise, 
FALSE.  A  location  is  in  bounds  if  the  x  and  v  coordinates  are  greater  than  0  and  less  than  GR.\- 
PHMAX. 


boolean  DBIsOccupled(x,  y) 

int  X,  y; 

IsOccupied  returns  TRUE  if  there  is  a  node  at  location  (z,  y)  in  the  current  data  base;  otherwise, 
FALSE. 
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boolean  DBIsValidName(name) 

char  ‘name: 

DBIsValidName  returns  TRUE  if  name  is  a  valid  name;  otherwise.  FALSE.  A  valid  name  starts 
with  an  alphabetic  character  .and  all  of  the  remaining  characters  are  alphanumeric. 


boolean  DBIsUniqNanie(name,  naflag) 

char  ‘name; 
int  naflag; 

DBIaUniqName  returns  TRUE  if  name  is  not  the  name  of  an  element  of  type  naflag  already  in  the 
current  data  base;  otherwise.  FALSE. 


DBSetNodeClass(n,  class) 
nodetype  n; 
int  class; 

DBSetNodeGlaas  sets  the  class  of  node  n  to  clasa.  This  routine  should  be  used  with  discretion, 
since  changing  the  class  of  existing  nodes  may  introduce  inconsistencies  in  the  data  base. 

DBClaaa  must  be  one  of  INTERNAL.  LEAF,  GRAPHJNPORT,  or  GRAPH_OUTPORT. 


int  DBGetNodeClass(n) 
nodetype  n; 

DBGetNodeClaaa  returns  the  class  of  node  n. 


DBMoveJunction(b,  j,  x,  y) 

bustype  b; 
int  j; 
int  X,  y; 

DBMove Junction  moves  junction  j  of  bus  b  to  the  new  location  (x,  y)  in  the  current  data  base. 


DBGetJunctionLoc(b,  j,  xp,  yp) 

bustype  b; 
int  j; 

int  *xp,  *yp; 

DBGetJunctionLoe  copies  the  (x,  y)  coordinates  of  junction  j  of  bus  b  into  the  integers  pointed  to 
by  xp  and  yp. 


DBGetJunctionCount(b) 

bustype  b; 

DBGtlJunclionCounl  returns  the  number  of  junctions  associated  with  bus  b. 
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int  DBGetConnectionCount(b,  j) 

buscype  b; 
iut  j; 

DBGetConnectionCount  returns  the  number  of  arcs  associated  with  junction  /  of  bus  b. 


DBGetOpenLoc(xp,  yp) 
int  *xp; 
int  *yp; 

DBGetOpenLoc  returns  the  coordinates  {xp.  yp)  of  an  unoccupied  location  in  the  current  graph. 
An  unoccupied  location  is  where  no  node  or  bus  junction  resides. 


boolean  DBNodeChange() 

DBNodeChange  returns  TRUE  if  the  list  of  node  names  for  the  current  data  base  has  changed 
since  the  last  call  to  DBNodeChange,  and  FALSE  otherwise.  The  list  of  node  names  changes  when 
a  node  is  added,  deleted,  or  renamed,  or  when  a  new  data  base  becomes  current. 


boolean  DBBusChange() 

DBBusChange  returns  TRUE  if  the  list  of  bus  names  for  the  current  data  base  has  changed  since 
the  last  call  to  DBBusChange,  and  FALSE  otherwise.  The  list  of  bus  names  changes  when  a  bus  is 
added,  deleted,  or  renamed,  or  when  a  new  data  base  becomes  current. 

DETERMINING  ATTRIBUTE  VALUES 

Because  ADASDB  prohibits  direct  manipulation  of  graph  element  structures,  the  following  rou¬ 
tines  must  be  used  to  access  to  graph  element  attributes.  All  attribute  values  are  maintained  as 
character  strings  which  must  be  interpreted  according  to  the  attribute’s  data  type  (see  DBGetAit- 
Type). 

An  attribute  for  a  graph  element  is  specified  by  giving  the  offset  of  that  attribute  in  the  element's 
attribute  list.  These  integer  offsets  are  constants  that  are  defined  in  the  ADAS  include  file 
<attributes.h>. 

Because  attributes  are  specified  as  offsets  into  an  attribute  list,  all  attributes  in  a  list  can  be 
enumerated,  without  having  to  know  about  each  individual  attribute,  by  simply  stepping  through 
the  list  one  attribute  at  a  time. 

Each  routine  in  this  section  returns  a  pointer  to  a  buffer  that  is  static  to  the  routine.  This  buffer 
is  overwritten  each  time  the  routine  is  called,  so  the  user  should  make  a  copy  of  the  siring  if  it 
needs  to  be  saved. 


char  *DBGetGraphAtt(att) 

int  att; 

DBGelGraphAtt  retrieves  the  value  of  attribute  ntiof  the  current  graph. 
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char  '*DBGetNodeAtt(n,  att) 

nodetype  n; 
int  att; 

DBGetNodeAtt  retvievei  the  value  of  attribute  affof  node  n. 


char’*  DBGetArcAtt(a,  att) 

arctype  a; 
int  att; 

DBGetArcAtt  retrieves  the  value  of  attribute  att  of  arc  a. 


char  *DBGetPortAtt(n,  port,  ioflag,  att) 

nodetype  n; 
int  port 
int  ioflag 
int  att; 

DBGetPortAtt  retrieves  the  value  of  attribute  att  of  inport  or  outport  port  on  node  n.  It  assumes 
ioflag  is  either  IN  (for  inport)  or  OUT  (for  outport). 

char  '*'DBGetBusAtt(b,  att) 
bustype  b; 
int  att; 

DBGitBvsAtt  returns  a  pointer  to  the  string  representation  of  the  value  of  attribute  att  of  bus  b. 

char  *DBGetPartitlonAtt(p,  att) 

parttype  p; 
int  att; 

DBGetPartitionAtt  returns  a  pointer  to  the  string  representation  of  the  value  of  attribute  att  of 
partition  p. 

SETTING  ATTRIBUTE  VALUES 

Because  ADASDB  prohibits  direct  manipulation  of  graph  element  structures,  graph  element  attri¬ 
butes  must  by  modified  using  the  following  routines. 

Each  routine  checks  the  modification  status  of  the  attribute  and  if  it  is  modifiable,  assigns  the 
indicated  value  to  that  attribute.  These  routines  return  XSTATUS  if  the  attribute’s  status  is  not 
MODIFY;  XFORMAT  if  the  attribute  value  has  a  bad  format  (in  terms  of  its  data  type,  see 
DBGetAttDataType);  and  XRANGE  if  the  attribute  value  is  out  of  range. 


DBSetGraphAtt(att,  attval) 

int  att; 
char  *attval; 

DBSetGraphAtt  assigns  attval  to  the  attribute  att  of  the  current  graph. 
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DBSetNodeAtt(n.  att,  attvai) 

nodetype  n; 
int  act: 

-■tiar  "'attvai: 

DRSetNodeAtt  assiens  attvnl  to  the  attribute  atf  of  node  n. 


DBSetArcAtt(a,  att,  attvai) 

arctype  a; 
int  att; 
char  *attvai; 

DBSetArcAtt  assigns  attvai  to  the  attribute  att  o{  arc  a. 


DBSetPortAtt(n,  port,  ioflag,  att,  attvai) 

nodetype  n; 
int  port; 
int  ioflag; 
int  att; 
char  *attval; 

DBSetPortAtt  assigns  attvai  to  the  attribute  alt  of  the  inport  or  outport  port  of  node  n.  It  assumes 
ioflag  is  either  IN  (for  inport)  or  OUT  (for  outport). 

DBSetBusAtt(b,  att,  attvai) 

bustype  b; 
int  att; 
char  "attvai; 

DBSetBusAtt  assigns  value  attvai  to  attribute  att  of  bus  6. 

DBSetPartitionAtt(p,  att,  attvai) 

parttype  p; 
int  att; 
char  *attval; 

DBSetPartitionAtt  assigns  value  attvai  to  attribute  att  of  partition  p. 

DETERMINING  ATTRIBUTE  STATUSES 

-A.  graph,  node,  arc,  or  port  attribute  may  have  one  of  four  modification  statuses;  (1)  MODIFY 
(attribute  is  modifiable),  (2)  NOMODIFY  (attribute  is  not  modifiable),  (3)  PROGMODIFY  (attri¬ 
bute  is  modifiable  by  an  .ADAS  program  only),  or  (4)  NOTUSED  (attribute  is  not  being  used).  .An 
element’s  attribute  statuses  are  determined  by  its  template. 


int  DBGetGraphAttStat(att) 

int  att: 

DBGetGraphAttStat  returns  the  modification  status  of  attribute  alt  of  the  current  graph. 
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int  DBGetNodeAttStat(n,  att) 

aodecype  n: 
int  att; 

DBGetNodeAttStat  Tuturns  the  modification  status  of  attribute  ati  of  node  n. 


int  DBGetArcAttStat(a,  att) 

arctype  a; 
int  att: 

DBGe tArcAttStat  retuTTis  the  modification  status  of  attribute  att  of  arc  n. 

int  DBGetPortAttStat(n,  port,  ioflag,  att) 

nodetype  n; 

int  port; 

int  ioflag; 

int  att; 

DBGetPortAttStat  returns  the  modification  status  of  attribute  att  of  inport  or  outport  port  on 
node  n.  It  assumes  ioflag  is  either  IN  (for  inport)  or  OUT  (for  outport). 

int  DBGetBusAttStat(b,  att) 

bustype  b; 
int  att; 

DBGetBusAttStat  returns  the  modification  status  of  attribute  att  of  bus  b. 

int  DBGetPartitionAttStat(p,  att) 
parttype  p; 
int  att; 

DBGetPartitionAttStat  returns  the  modification  status  of  attribute  att  of  partition  p. 

SETTING  ATTRIBUTE  STATUSES 

The  following  routines  change  an  attribute’s  status.  These  routines  are  meant  for  template  edit¬ 
ing  and  should  not  be  used  for  other  applications  since  changing  attribute  statuses  can  have 
unpredictable  side-effects. 

Status  must  be  either  MODIFY  (the  attribute  is  modifiable),  NOMODIFY  (the  attribute  is  not 
modifiable),  PROCMODIFY  (the  attribute  is  modifiable  by  an  .-VDAS  program  only),  or 
NOTUSED  (the  attribute  is  not  needed). 

DBSetGraphAttStat(att,  status) 

int  att; 
int  status; 

DBS'etGraphAttStat  sets  the  modification  status  of  attribute  all  of  the  current  graph  to  .staln-i. 
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DBSetNodeAttStatfn,  att,  status) 

;io(ietvpe  n: 
int  alt: 
iru  status; 

DBSe.tNode.AltStat  sets  the  modification  status  of  attribute  utt  of  node  n  to  -itatufi. 


DBSetArcAttStat(a,  att,  status) 

arctype  a: 
int  att: 
int  status; 

DBSetArcAttiitat  sets  the  modification  status  of  attribute  att  of  arc  a  to  -status. 


DBSetPortAttStat(n,  port,  ioflag,  att,  status) 

nodetype  n; 
int  port; 
int  ioflag; 
int  att; 
mt  status: 

DBSetPortAttStat  sets  the  modification  status  of  attribute  att  of  inport  or  outport  port  on  node  n 
to  status.  It  assumes  ioflag  is  either  IN  (for  inport)  or  OUT  (for  outport). 


int  DBSetBusAttStat(b,  att,  status) 
bustype  b: 
int  att; 
int  status; 

DBSetBusAttStat  sets  the  modification  status  of  attribute  att  of  bus  b  to  status. 


int  DBSetPartitionAttStat(p,  att,  status) 

parttype  p; 
int  att: 
int  status: 

DBSetPartitionAttSlat  sets  the  modification  status  of  attribute  alt  of  partition  p  to  status. 
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DETERMINING  ATTRIBUTE  DATA  TYPES 


The  iiCT.ributes  .associated  with  each  kind  ol'  ^jrapii  element  have  data  types.  Since  attr'ibures  are 
stored  as  character  strings,  an  attribuce's  data  type  must  iae  known  to  interpret  the  siring.  .Attri¬ 
bute  data  types  are  bound  in  an  rJ.tribiite.  re.mviatti  that  is  defined  in  the  ADASDB  library.  An 
ittnbuteks  uata  type  can  be  one  of  INTEGER.  LABEL.  IDENTIFIER.  COORDINATE.  TEXT. 
FILENAXlE,  or  FLOAT.  Once  an  attribute  s  data  type  is  known,  standard  UNIX  functions  (e.g.. 
atoi.  atof,  etc.)  may  be  used  to  interpret  that  attribute. 


int  DBGetGraphAttTypefatt) 

ini  alt: 

DBGetGraphAttType  returns  the  data  type  of  the  gr.aph  attribute  att. 

int  DBGetNodeAttType(att) 

int  att; 

DBGetNodeAttType  returns  the  data  type  of  the  node  attribute  att. 


int  DBGetArcAttType(att) 
int  att; 

DBGetArcAttTypfi  returns  the  data  type  of  the  .arc  attribute  att. 

int  DBGetPortAttType(ioflag,  att) 
int  ioflag; 
int  att; 

DBGttP art AttT type  returns  the  data  type  of  the  port  attribute  att.  It  assumes  ioflag  is  either  IN 
(for  inport)  or  OUT  (for  outport). 

int  DBGetBusAttType(att) 

int  att; 

DBGetBu.sAttType  returns  the  data  type  of  the  bus  attribute  att. 


int  DBGetPartitionAttType(att) 

int  att; 

DBGetPartitionAttType  returns  the  data  type  of  the  partition  attribute  att. 
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DETERMINING  ATTRIBUTE  EXISTENCE 


boolean  DBGraphAttExists(att) 

ini  act; 

DBGraptiAttExists  returns  TRUE  if  the  graph  attribute  att  exists  in  the  current  data  base,  and 
FALSE  otherwise. 


boolean  DBNodeAttExists(att) 

int  att; 

DBNodeAttExists  returns  TRUE  if  the  node  attribute  att  exists  in  the  current  data  base,  and 
F.\LSE  otherwise. 


boolean  DBArcAttExists(att) 
int  att; 

DBArcAttExists  returns  TRUE  if  the  arc  attribute  att  exists  in  the  current  data  base,  and  F-ALSE 
otherwise. 


boolean  DBBusAttExists(att) 
int  att; 

DBBusAttExists  returns  TRUE  if  the  bus  attribute  att  exists  in  the  current  data  base,  and  FALSE 
otherwise. 


boolean  DBPartitionAttExists(att) 
int  att; 

DBPartitionAttExists  returns  TRLTi  if  the  partition  attribute  att  exists  in  the  current  data  base, 
and  FALSE  otherwise. 


boolean  DBPortAttExists(p,  att) 

int  p; 
int  att; 

DBPortAttExists  returns  TRUE  if  the  port  attribute  alt  of  port  type  p  (IN,  OLiT,  or  Bl)  exists  in 
the  current  data  base,  and  FALSE  otherwise. 
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DETERMINING  ATTRIBUTE  MODIFIABILITY 


boolean  DBGraphAttlsMoci(att) 

ini  alt; 

DBGravhAttlsMod  returns  TRLIE  if  graph  attribute  atl  is  modifiable,  and  F.ALSE  otherwise. 


boolean  DBNodeAttlsMod(att) 

int  alt: 

DBNodeAttlsMod  returns  TRUE  if  node  attribute  att  is  modifiable,  and  FALSE  otherwise. 


boolean  DBArcAttlsMod(att) 

int  att: 

DBNodeAtllsMod  returns  TRUE  if  node  attribute  att  is  modifiable,  and  FALSE  otherwise. 


boolean  DBBusAttlsMod(att) 

int  att; 

DBBusAttlsMod  returns  TRLTl  if  bus  attribute  att  is  modifiable,  and  FALSE  otherwise. 


boolean  DBPartitionAttlsMod(att) 

int  att; 

DBPartitionAttlsMod  returns  TRUE  if  partition  attribute  att  is  modifiable,  and  F.ALSE  otherwise. 


boolean  DBPortAttIsMod(p,  att) 

int  p; 
int  att; 

DBPortAttlsMod  returns  TRUTI  if  attribute  att  of  port  type  p  (IN,  OUT,  or  BI)  is  modifiable,  and 
FALSE  otherwise. 

DETERMINING  ATTRIBUTE  REQUIRED  STATUS 

boolean  DBGraphAttlsReq(att) 

int  att; 

DBGraphAttlsReq  return.s  TRUE  if  graph  attribute  att  is  marked  as  required,  and  F.ALSE  other¬ 
wise. 


boolean  DBNodeAttlsReq(att) 

int  att; 

DBNodeAUlsReq  returns  TRUE  if  node  attribute  att  is  marked  as  required,  and  F.-VLSE  otherwise. 


Appendix  D,  11-38 


boolean  DBArcAttlsReq(att) 

int  att; 

DBAreAttlsReq  returns  TRUE  if  arc  attribute  att  is  marked  as  required,  and  F.ALSE  otherwist". 


boolean  DBBusAttlsReq(att) 
int  att: 

DBBusAttlsReq  returns  TRUE  if  bus  attribute  att  is  marked  as  required,  and  F.\LSE  otherwise. 


boolean  DBPartitionAttlsReq(att) 

int  att; 

DBPartitionAtthReq  returns  TRUE  if  partition  attribute  att  is  marked  as  required,  and  F.ALSE 
otherwise. 


boolean  DBPortAttIsReq(p,  att) 
int  p; 
int  att: 

DBPortAttlsReq  returns  TRUE  if  attribute  att  of  port  type  p  is  marked  as  required,  and  F.\LSE 
otherwise. 

DETERMINING  ATTRIBUTE  SAVE  STATUS 

boolean  DBGraphAttlsSave(att) 
int  att; 

DBGraphAtthSave  returns  TRUE  if  graph  attribute  att  is  savable,  FALSE  otherwise. 


boolean  DBNodeAttlsSave(att) 
int  att; 

DBNodeAtthSave  returns  TRUE  if  node  attribute  att  is  savable.  FALSE  otherwise. 


boolean  DBArcAttlsSave(att) 

int  att; 

DBArcAltlsSave  returns  TRUE  if  arc  attribute  att  is  savable,  FALSE  otherwise. 


boolean  DBBusAttlsSave(att) 

int  att; 

DBBusAltlsSave  returns  TRUE  if  bus  attribute  att  is  savable.  FALSE  otherwise. 
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boolean  DBPartitionAttlsSave(att) 

int  ate: 

DBPartitionAttlsSave  returns  TRL^E  if  partition  attribute  ait  is  savahie.  F.\LSE  otherwise. 


boolean  DBPortAttIsSave(p,  att) 
int  p: 
int  att; 

DBPortAttlsSave  returns  TRLfE  if  attribute  att  of  port  type  p  is  savable.  F.ALSE  otherwise. 

SETTING  ATTRIBUTE  SAVABILITY 

DBMakeGraphAttSave(att) 
int  att; 

DBMakeGraphAttSave  makes  graph  attribute  savable  in  the  current  data  base. 


DBMakeGraphAttNotSave(att) 
int  att; 

DBMakeGrapkAttNotSave  makes  graph  attribute  aU  unsavable  in  the  current  data  base. 


DBMakeNodeAttSave(att) 
int  att; 

DBMakeNodeAttSave  makes  node  attribute  att  savable  in  the  current  data  base. 


DBMakeNodeAttNotSave(att) 
int  att; 

DBMakeNodeAttNotSave  makes  node  attribute  att  unsavable  in  the  current  data  base. 


DBMakeArcAttSave(att) 
int  att; 

DBMakeArcAttSave  makes  arc  attribute  alt  savable  in  the  current  data  base. 


DBMakeArcAttNotSave(att) 
int  att; 

DBMakeArcAttNolSave  makes  arc  attribute  alt  unsavable  in  the  current  data  base. 
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DBMakeBusAttSave(att) 

int  atr,: 

DBMakeBusAttSavf.  makes  bus  at, tribute  a<f  savable  in  the  i-urreut  data  base. 


DBMakeBusAttNotSave(att) 
int  att: 

DBMakeBusAttNotSavf.  makes  bus  attribute  att  unsavable  in  the  current  data  base. 


DBMakePartAttSave(att) 

int  att; 

DBMakePartAftSave  makes  partition  attribute  savable  in  the  current  data  base. 


DBMakePartAttNotSave(att) 

int  att: 

DBMakePartAttNotSave  makes  partition  attribute  att  unsavable  in  the  current  data  base. 


DBMakePoptAttSave(type,  att) 
int  type; 
int  att; 

DBMakePortAttSave  makes  attribute  att  of  port  type  type  savable  in  the  current  data  base. 


DBMakePortAttNotSave(type,  att) 
int  type; 
int  ati; 

DBMakePortAttNotSave  makes  attribute  aft  of  port  type  type  unsavable  in  the  current  data  base. 
DETERMINING  ATTRIBUTE  NAMES 

Each  graph,  node,  arc,  and  port  attribute  has  a  short,  descriptive  name  that  can  be  retrieved  wit 
the  following  routines.  These  routines  all  assume  att  is  a  valid  attribute. 


char  *DBGetGraphAttName(att) 

int  att; 

DBGetGraphAttName  returns  the  name  of  the  graph  attribute  att. 


char  *DBGetNodeAttName(att) 

int  att; 

DBGetNodeAtlName  returns  the  name  of  the  node  attribute  att. 
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char  *DBGetArcAttName(att) 

int  art: 

DBGitArcAttNnmc  returns  the  name  of  the  arc  attribute  att. 


char  *DBGetPortAttNaine(att,  ioflag) 

int  ioflag; 
int  att: 

DBGctPortAttName  returns  the  name  of  the  port  attribute  att.  It  assumes  ioflag  is  either  IN  (for 
inport)  or  OUT  (for  outport). 


char  *DBGetBusAttNaine(att) 
int  att; 

DBGetBusAttName  returns  the  name  of  the  bus  attribute  att. 


char  *DBGetPartitiotiAttName(att) 
int  att; 

DBGetPartitionAttName  returns  the  name  of  the  partition  attribute  att. 

RETRIEVING  GRAPH  ELEMENT  TEMPLATES 

Templates  are  kept  in  files  separate  from  the  graph  data  bases.  A  template  is  retrieved  by  specify¬ 
ing  a  template  file  search  path.  This  search  path  is  a  string  consisting  of  the  template  file  names, 
separated  by  commas,  that  are  to  be  searched  for  templates. 

Template  files  are  searched  in  the  order  they  appear  in  the  path,  and  the  search  terminates  either 
when  the  template  is  found  or  all  files  in  the  path  have  been  searched. 

The  template  retrieval  routines  returns  XACCESS  if  a  file  in  the  template  search  path  could  not 
be  opened  for  reading,  XFORMAT  if  a  template  file  has  a  bad  format,  XEOF  if  end-of-file  was 
reached  prematurely  while  reading  a  template  file.  XMEMORY  if  there  is  not  enough  memory  to 
perform  the  search,  and  XNOTFOUN'D  if  the  template  was  not  found  in  any  of  the  files  in  the 
search  path. 


DBSetTSPath(path) 

char  *path; 

DBSe.tTSPath  sets  the  template  search  path  to  path. 

Returns  XFORMAT  if  path  has  an  improper  format  or  is  longer  than  NLVXP.ATH  characters,  or 
XMEMORY  if  it  couldnT  allocate  space  for  the  path  string. 
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char  *DBGetTSPath(n) 

int  n: 

DBGe.tTSParJi  returns  the  nth  component  of  the  template  search  path,  or  ,\'T7LL  if  rhere  is  no  nth 
component. 


DBGetNodeTeinplate(naine,  tp) 
char  "name; 
nodetype  *tp; 

DBGetNodeTemplate  retrieves  the  node  template  name  from  one  of  the  template  files  specified  in 
the  template  search  path.  It  sets  the  pointer  Ip  to  point  to  the  template. 


DBGetArcTemplate(name,  tp) 
char  "name; 
arctype  *tp; 

DBGetArcTemplate  retrieves  the  node  template  name  from  one  of  the  template  files  .specified  in 
the  template  search  path.  It  sets  the  pointer  tp  to  point  to  the  template. 


DBGetBusTemplate(name,  tp) 
char  "name; 
bustype  "tp; 

DBGetBnsTernplate  retrieves  the  bus  template  name  from  one  of  the  template  files  specified  in  the 
template  search  path.  It  sets  the  pointer,  pointed  to  by  tp.  to  point  to  the  bus  template. 


DBGetPartitionTemplate(tp) 
parttype  "tp; 

DBGetPartitionTemplate  gets  the  partition  template  from  the  master  template  file.  Unlike  other 
graph  elements,  all  partitions  are  created  from  a  single  partition  template.  The  pointer  tp  is  set  to 
point  to  the  partition  template. 
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TABLE  OF  ADASDB  ERROR  CODES 


The  loilowini^  eonstancs  represent  the  possible  values  ol’  rhe  external  error  flag  iberrno.  The  gen¬ 
eral  ineanins?  of  each  error  code  is  provided  here.  For  more  .specific  information,  see  rpe  error  coae 
information  in  the  description  for  the  individual  routines. 


XINIT 

XLACCESS 

XEOF 

:tformat 

XXIEMORY 

XRAXGE 

XLEVEL 

XLOCATION 

XNAVIE 

XNOTFOUND 

XPORT 

XSTATUS 

XEXPAND 


initialization  error 

canh  access  external  <lata  base  file 

premature  EOF  when  reading  externai  data  base  file 

external  data  base  format  is  i)ad.  etc. 

ran  out  of  memory  jmailoc  failed) 

attribute  value  is  out  of  range 

graph  level  too  deep  or  siiallow 

grid  location  out  of  bounds,  etc. 

bad  node  or  arc  name 

template,  node.  etc.  not  found 

invalid  port 

invalid  node  class  or  attribute  status 
node  subgraph  is  (not)  already  expanded 
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A  SAMPLE  PROGRAM 


This  r,oy  program  is  designed  ro  demonstrate  some  basic  usage  of  the  AZ)A5DB  routines.  It  read 
in  a  data  base,  fiddles  with  the  node  utilization  attributes,  tries  to  expand  a  node,  then  exits. 


^include  <adas.h> 
j^include  <adasdb.h'> 

^include  <  attributes. h  .> 

main!) 

{ 

int  gd:  *  graph  descriptor  *  ' 

nodetype  n:  *  a  node  in  the  current  data  base  */ 

char  *DBGetNodeName();  ;  *  ,4DASDB  routine  for  getting  node  name  *  ' 


*  Read  in  the  graph  data  base  foo.swg’. 

if  ((gd  =  DBGraphInit( “foo.swg" )  <  0) 

{ 

switch  (dberrno) 

{ 

case  XINIT; 

printf(“too  many  graphs  initialized  alreadyXn"); 
break: 

/*  etc...  */ 

} 

exit(l); 

} 

DBUseGraph(gd); 


/*  Set  utilization  of  all  nodes  in  the  current  data  base. 

*  For  each  node  in  the  current  data  base, 

*  print  out  old  utilization  value 

*  then  set  and  print  new  value. 

*i 

DBSetFirstNode(); 
while  (DBMoreNodes()) 

{ 

DBGetNextNode(&n); 

printf("utilization  of  node  ^s  was  %s,", 
DBGetNodeName(n),  DBGetNodeAtt(n,  NUTIL)): 

if  (DBSetNodeAtt(n, NUTIL, “0.667")  !=  0) 
printf( "Oops!  can’t  set  node  utilization. \n”); 
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Isp  printff '' but  now  it  is  %s\n‘'.  DBGetNodeAtt(n.  NUTIL)); 


'*  Find  a  node  ealied  foonode'  in  the  current  data  base. 

*  make  sure  it  is  an  internal  node,  then  expand  it. 

*  Change  the  current  data  base  to  the  expanded  subgraph. 

*  then  come  back. 

*  / 

if  (DBGetNodeByName(  "foonode" .  &n)  !=  0) 
printf(" can’t  find  node  ’foonode'\n"); 

else  if  (  DBGetNodeCIass(n)  !=  INTERNAL) 

printff  "node  foonode’  is  not  an  internal  node\n"); 

else  if  (DBSubgraphInit(n,"foo.swt“)  !=  0) 

printff  "can’t  expand  subgraph  of  node  ’foonode’\n“); 

else 

/ 

i 

fvoidlDBPushDbfn); 

fvoid)DBPopDh(); 

} 


/*  Clean  up  after  ourselves  before  exiting. 
*  / 

DBTermGraphf); 

exitfO); 
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PART  m 


ADAS  Command  Interpreter  Routines 


INTRODUCTION 

The  .\DAS  command  interpreter  (libci)  is  responsible  for  building  and  dispiaynig  menus,  display¬ 
ing  prompts,  and  interpreting  input  for  ADAS  client  programs.  A  client  program  gives  the  com¬ 
mand  interpreter  a  top-level  command  list;  the  program  gives  a  list  of  pointers  ro  functions  ro  be 
executed  when  the  corresponding  commands  are  chosen.  For  menus  other  than  the  top  one.  client 
programs  build  the  menus  and  prompt  and  pass  them  to  the  command  interpreter,  which  returns 
the  user  input. 

ciExecCmd() 

ciExecCmd  is  the  top-level  routine  called  by  clients  using  the  .ADAS  command  interpreter.  It 
starts  up  the  command  interpreter  with  the  client  program’s  top-level  menu  and  execute.s  com¬ 
mands  from  that  menu. 

cilnit(menu,  list) 

menutype  menu[]; 
functype  list[]; 

cilnit  initializes  the  command  interpreter’s  command  menu  and  command  function  list  for  the 
current  program.  It  does  this  by  setting  pointers  to  the  menu,  menu  and  the  function  list,  li/it.  It 
also  sets  the  count  of  the  number  of  commands  in  the  menu. 

Ci(canon_form,  menu,  validate,  prompt,  help,  tokenp) 

int  canon_form; 

menutype  *menu; 

int  (*validate)(); 

char  *prompt,  *help; 

tokentype  *tokenp; 

Ci  displays  the  menu  pointed  to  by  menu,  sets  prompt  and  help  as  the  prompt  and  help  messages, 
respectively,  and  gets  the  next  token  in  the  input.  The  expected  canonical  form  and  the  valida¬ 
tion  function  for  the  token  are  canon _form  and  validate.  Ci  sets  tokenp  to  point  to  the  new  token. 
It  returns  ESCAPE  if  the  token  is  a  special  token  and  CANCEL  if  the  command  is  canceled  either 
by  the  user  or  because  of  too  many  tries  to  get  an  acceptable  token. 

int  ciV alidRepeat(token_val , tokenp) 
char  *token_val; 
tokentype  *tokenp; 

ciValidRepeat  returns  0  if  token_val  is  a  valid  token  value  representing  a  number  of  repetitions  for 
a  command  (any  integer),  and  -1  if  it  is  not.  This  routine  checks  only  the  syntax  of  the  repetition 
count,  not  the  range.  If  the  count  is  valid,  tokenjual  is  copied  into  the  token  pointed  to  by  tok¬ 
enp. 

CANONICAL  FORMS 

Each  token  that  the  command  interpreter  processes  has  associated  with  it  a  canonical  form  which 
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the  client  program  expects  it  to  match.  There  are  nine  different  canonical  forms:  INTEGER. 
REAL,  coordinate’  IDENTIFIER.  TEXT.  NODE.  .\RC.  PT'NCTU.\TION.  and  NEWLINE. 

int  ciConvertToCanon(tokeii_val,  token  type,  canon  form,  tokenp) 

char  token_valij: 
int  token_type; 
int  canon_form: 
tokentype  ‘tokenp; 

ciConvertToCanon  uses  the  canonical  form,  canon _form  and  the  token  type.  token_type  to  convert 
the  token  value  toktnjoal  into  the  appropriate  form  and  assigns  it  to  the  token  pointed  to  by  tok¬ 
enp.  It  returns  0  if  tokenjoal  was  successfully  converted  and  -1  if  the  conversion  could  not  be 
accomplished. 

boolean  ciPickFromGraph() 

ciPickFromGraph  returns  TRLTE  if  the  last  token  converted  by  ciConvertToCanon  was  the  result 
of  a  graph  pick  and  F.ALSE  otherwise. 

CONTEXT 

These  routines  provide  context  information  in  a  message  included  in  the  command  interpreter 
prompt.  This  message  reflects  the  command  sequence  which  put  the  command  interpreter  into  its 
current  state,  starting  from  the  main  menu. 

ciEnableContextString(oiv) 
boolean  on: 

ciEnableContextString  enables  the  command  interpreter's  context  string  mechanism  if  on  is 
TRUE,  and  disables  it  otherwise. 

int  ciContextLevel() 

ciContextLevel  returns  the  value  of  the  static  variable  contextjevel. 

ciInitContext() 

cilnitContexl  initializes  the  value  of  the  static  variable  contextjevel  to  0  to  indicate  that  the  main 
menu  is  the  current  menu. 

ciSetContextLevel() 

ciSetContextLevel  increments  the  static  variable  contextjevel  to  record  the  descent  into  a  sub¬ 
menu  of  the  current  menu. 

ciMakeContextString(canon_form,  tokenp) 

int  canon_form; 
tokentype  ‘tokenp; 

ciMakeConlextSlring  builds  the  command  context  string  up  to  two  levels  deep  for  the  command 
specified  in  the  token  pointed  to  by  tokenp  and  also  having  canonical  form,  canon Jorm. 

boolean  CommandOK(command) 
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char  *command: 


C7ommanc/OA’ determines  if  •ommund  is  ",uid.“  "delete."  "edit."  "environ."  "move."  or  "simu¬ 
late."  and  is.  therefore,  one  of  the  main  menu  commands  for  which  context  information  should  be 
displayed.  It  returns  TRL'E  if  •nmmanri  is  in  this  .set  and  F.ALSE  otherwise. 
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ciPrintContext  () 

ciPrrntContext  displays  i’ommand  concext  information  on  the  terminal  screen. 

ConvertToUpperCase(tempstring) 

char  "tempstnng; 

ConveTtToUpptrCa.se.  converts  tempstring  to  all  upper  case. 

boolean  CFormOK(canon_form) 

int  canon_l'orm: 

CFormOK  checks  that  the  canonical  form  canon _Jorm  is  appropriate  for  use  as  a  context  message, 
i.e.,  is  either  IDENTIFIER  or  TEXT.  It  returns  TRUE  if  the  form  is  acceptable  and  F.\LSE  other¬ 
wise. 

ciContextSave() 

ciContextSave  saves  both  the  current  context  string  and  the  context  level  to  be  restored  later  with 
ciContextRestore.  This  is  done  when  a  help  command  is  issued,  allowing  for  a  return  to  the 
current  menu. 

ciContextRestore() 

ciContextRestore  restores  the  context  information  saved  by  ciContextRestore. 
ciSetHelpContext() 

ciSetHelpContext  sets  the  context  message  and  level  for  the  help  command. 

ERROR  HANDLING 

ciSetErrorFlag(value) 
boolean  value; 

ciSetErrorFlag  sets  the  error  flag  indicating  incorrect  input  to  value,  which  should  be  either  TRLTi 
or  FALSE. 

boolean  ciErrorFiag() 

ciErrorFlag  returns  the  value  of  the  error  flag  used,  indicating  the  incorrect  input. 

HANDLING  INPUT 

int  ciGetTokenDirect(token_buf) 
char  token_buf(j; 

ciGetTokenDirect  gets  a  token  string  directly  from  input  and  puts  it  into  token_buf.  If  the  string 
specifies  a  shell  escape,  ciGetTokenDirect  calls  DoShetl  with  that  token  and  gets  the  next  one.  It 
returns  the  type  of  the  token. 

char  *ciExtractToken(stringp) 
char  **stringp; 
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I'iEjutractTohen  finds  the  next  token  in  the  string  pointed  to  bv  .-itnriiip  and  teiurns  '!  pointe:’  'o  it. 
In  this  context,  a  token  :s  a  string  of  one  or  more  non-biank  haracters.  The  pointer  ooimea  to  ny 
.■ffn'nop  is  updated  to  point  to  the  next  toicen  in  the  string,  if  no  token  'vas  fotinii.  ciS.rtrnciToK-i'.n 
returns  .VULL. 

ciFillQueue() 

ciFrllQuene  gets  tokens  and  fills  the  token  queue,  if  a  token  specifies  a  shell  “scape.  .■iFillOue.ue. 
calls  DoSheil  to  handle  it.  otherwise  it  adds  the  token  to  the  token  oueue. 

int  ciGetToken(using_queue,  token  val) 
int  using_queue; 
char  token_val!j; 

ciGttTokan  gets  a  token  string  anti  puts  it  into  token_val.  [f  is  TRI  E.  the  token  is 

retrieved  from  the  token  queue  with  ciQntueGel.  otherwise  it  comes  from  ■•■iGtlTokcnDire.ci.  It 
returns  (1)  the  token’s  lexical  type  upon  normal  completion.  (2)  ESCAPE  when  the  token  is  the 
escape  token,  and  (3)  CANCEL  when  the  token  is  the  cancel  one. 

char  ’"clGetlnputO 

ciGetInput  reads  the  next  line  from  the  script  file  if  one  is  being  used.  Otherwise,  it  oolls  the  key¬ 
board  and  data  tablet  for  input,  [f  input  is  received  from  the  tablet.  ciGttlnpnl  converts  the  coor¬ 
dinates  into  a  token  using  ciTranxfonnPick.  It  returns  a  pointer  to  a  static  buffer  containing  the 
input. 

char  *ciTransforinPick(ndcx,  ndcy) 

double  ndcx,  ndcy; 

ciTransformPick  transforms  the  normalized  device  coordinates  {ndcx.  ndcy)  into  a  string  and 
returns  a  pointer  to  the  string  or  NLT.L  if  the  transformation  is  unsuccessful.  If  the  location  is 
within  a  menu,  the  string  is  the  appropriate  menu  entry.  Otherwise,  it  is  the  string  representation 
of  the  location  in  graph  (.ADAS  grid)  coordinates. 

boolean  ciPickInMenu(ndcx,  ndcy,  whichmenu) 

double  ndcx,  ndcy; 
int  whichmenu; 

ciPickInMenv,  returns  TRUE  if  the  pick  at  (ndcx,  ndcy)  is  inside  the  menu  specified  by  whichmenn. 
and  F.ALSE  otherwise. 

char  ’''ciGetMenuItem(ndcx,  ndcy,  screen_Ioc) 
double  ndcx.  ndcy; 
int  screen_loc; 

ciGetMenuItem  returns  a  pointer  to  a  string  containing  the  menu  entry  located  at  (ndcx.  ndcy) 
and  contained  in  the  menu  specified  by  screenjoc.  The  value  of  .^crcenjoc  is  0  for  the  auxiliary 
menu  and  1  for  the  main  menu. 

boolean  ciInGraph(ndcx,  ndcy) 

double  ndcx,  ndcy; 

cilnGraph  returns  TRUE  if  the  location  (ndcx,  ndcy)  is  inside  the  graph  window. 
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char  *ciGetGraphItem(ndcx,  ndcy) 

double  idcx.  ndcy; 

ciGetGraphltem  returns  n  pointer  to  a  strinir  ’-virdi  the  string  representation  of  riie  grapii  ;ADAS 
grid)  coordinates  corresponding  lo  NDC  location  i  ndex,  ndcy). 

MACROS 

A  macro  is  simply  a  user-defined,  named  sequence  of  commands  and  rheir  parameters.  Macros  -an 
be  written  so  parameter  values  are  given  at  the  time  the  macro  is  used  by  substituting  a  place 
holder  (’$’)  for  each  parameter  which  will  be  filled  in  later. 

int  ciAddMacro() 

ciAddMacro  gets  a  macro  definition  from  input,  adds  the  macro  to  the  command  list,  and  ioads  it 
into  the  macro  data  structure. 

int  ciDeleteMacro() 

ciDeleteMaero  allows  the  user  to  select  the  macro  to  be  deleted  from  a  menu,  then  it  ileietes  the 
macro  from  the  command  set  and  from  the  macro  data  structure. 

ciListMacroDefs() 

ciListMacroDefs  displays  each  currently  defined  macro  and  its  definition  on  the  terminal  screen. 

ciDoMacro(index) 
int  index: 

DoMacro  prepares  for  the  execution  of  the  macro  in  position  index  in  the  macro  list.  If  the  macro 
definition  has  no  place  holder  for  parameters,  it  is  pushed  onto  the  token  queue.  Otherwise,  it  is 
pushed  onto  an  auxiliary  queue  and  a  flag  is  set  indicating  its  presence  there. 

ciGetMacro() 

ciGetMacro  gets  a  macro  definition  from  input  and  puts  it  into  the  token  queue. 

boolean  ciIsAConimand(token_val) 
char  *token_val; 

cihACommand  returns  TRUE  if  token_val  is  the  name  of  a  command  from  the  command  menu 
and  FALSE  otherwise. 

ciClearMacro(index) 

int  index; 

ciClearMacro  resets  the  individual  macro  data  structure  with  index  index  to  empty. 

ciCompactMacroList(index) 

int  index; 

ciCornpactMacroList  compacts  the  macro  data  structure  to  eliminate  macro  number  index  by 
shifting  all  macros  following  index  up  one  place  in  the  list. 
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ciCompactMacroMenu(index.  menu) 

int  index; 
menutype  *menu: 

ciCornpactMacroMenu  i;ompacr.s  the  macro  menu  pointed  to  by  menu  to  eliminate  macro  number 
index  by  shifting  all  macros  foilowim?  index  up  one  place  in  the  menu. 

boolean  ciEmbeddedPlaceHoiderl  macroindex) 
int  macroindex: 

ciEmbeddedPtaceHolder  returns  TRUE  if  there  is  an  embedded  parameter  placeholder  in  the  defin¬ 
ition  of  macro  number  macroindex,  .and  FALSE  otherwise.  .\n  embedded  placeholder  is  one  that  is 
followed  in  the  macro  definition  bv  an  argument  that  is  not  a  placeholder. 

MENUS 

.Aji  ADAS  menu  consists  of  a  list  of  strings  —  the  menu  entries  --  each  with  an  associated  color 
which  is  used  when  the  menu  item  is  displayed  on  the  graphics  screen.  A  menu  contains  an  empty 
string  ("")  as  its  last  entry,  marking  rhe  end  of  the  menu. 

ciShowMenu() 

ciShowMenv  erases  the  existing  menu  from  the  graphics  display  and  draws  the  current  page  of  the 
current  menu  on  the  terminal  screen  and  the  graphics  display. 

ciShowAuxMenu() 

eiShowAuxMenu  draws  the  auxiliary  menu  on  the  terminal  screen. 

ciEraseMenu() 

ciEraseMenu  sets  the  current  menu  pointer  to  NLILL. 

int  ciGetMenuIndex(s,  menu) 
char  *s; 

menutype  *menu; 

ciGetMenulndex  returns  the  index  of  the  entry  .5  in  the  menu  pointed  to  by  menu.  It  returns  -I  if 
■s  is  not  in  menu,  or  -2  if  -5  is  a  prefix  of  more  than  one  entry. 

char  *ciGetMenuEntry(index,  menu) 

int  index; 
menutype  *menu; 

ciGetMenuEnlry  returns  a  pointer  to  entry  number  index  in  menu.  It  assumes  menu  isn't  .NULL 
and  index  is  the  index  of  a  valid  entry.  ciGetMenuEntry  returns  a  static  buffer  that  is  overwritten 
on  subsequent  calls. 

int  ciAddMacroToMenu(item,  menu) 
char  *item; 
menutype  ‘menu; 
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ctAddMacroTi)i\[enu  adds  the  ^ni  ■■  'tern  t,o  the  end  of  the  menu  pointed  to  by  menu  in  the  color 
illLLOW.  Actually,  rhe  new  entry  is  added  in  the  ne>:t-to-lasr  position,  just  before  the  "empty" 
entry  that  signals  the  end  of  the  menu. 

ciSetMeiiu(menu) 

menutype  “menu: 

nSetMenn  sets  the  current  menu  pointer  to  the  menu  pointed  to  by  menu.  The  current  page  is 
set  to  the  first  page  ;page  0). 

ciUnsetMenu() 

•AbnsetMenu  unsets  the  current  menu.  The  current  menu  is  .set  to  a  new,  blank  menu  with  no 
entries. 

ciPageMenu() 

ciPaqeMenu  turns  to  the  next  page  of  the  current  menu.  If  the  current  page  is  the  last  page  in  the 
menu  or  the  next  page  is  blank,  it  wraps  around  to  the  first  page.  ciPngeMenu  assumes  menu 
pages  are  numbered  from  0  to  MENU_PAGES  -  1. 

ciDrawMenu(flag) 

int  flag; 

ciDrawMenn  displays  the  items  of  the  current  menu  in  the  menu  area  of  the  graphics  display.  If 
flag  is  0  the  menu  is  erased:  otherwise  it  is  drawn. 

ciDrawAuxMenu(flag) 

int  flag, 

ciDratvAuxMenn  displays  the  items  of  the  auxiliary  menu  in  the  auxiliary  menu  area  of  the  graph¬ 
ics  display.  If  flag  is  0,  menu  is  erased,  otherwise  it  is  drawn. 

char  •ciGetCurrMenuItem(slot,  screen_loc) 

int  slot: 
int  screen_loc; 

ciGelCurrMenuItem  returns  the  contents  of  slot  number  slot  in  the  menu  specified  by  screen  loc. 
If  screen_loc  is  1,  a  pointer  to  t»ie  entry  in  slot  slot  ol  the  current  menu  is  returned.  Otherwise,  it 
returns  a  pointer  to  a  string  containing  only  the  first  character  of  auxiliary  menu  entry  number 
slot.  This  is  the  special  character  denoting  an  auxiliary  menu  entry. 

ciMakeMenu(inenu) 
menutype  **menu: 

ciMakeMenu  creates  a  new  menu  of  size  MENU_MAX  and  initializes  all  its  entries  to  the  empty 
string.  The  pointer  pointed  to  by  menu  is  set  to  point  to  the  new  menu. 

ciMenuAdd(menu,  item,  color) 

menutype  **menu: 
char  *item; 
int  color: 
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cxMenuAdd  adds  the  entry  item  to  the  menu  pointed  'o  by  rhe  pointer  ooinred  ‘o  bv  me.nn.  The 
new  entry  will  be  displayed  in  the  eolor  r.olor.  The  new  entry  iS  .-necked  ro  msure  -iiat  mere 
not  an  existing  entry  of  the  same  name.  If  not,  the  new  entry  is  placed  in  rlie  first  a',  ailaitle  ^iot  m 
the  menu. 

ciFreeMenu(menu) 
menutype  ‘menu: 

ciFreeMenu  frees  the  memory  occupied  by  menu. 

ciMenuDel(menu,  item) 
menutype  ‘menu: 
char  ‘item; 

ctMenuDel  deletes  the  entry  item  from  the  menu  pointed  to  by  menu.  All  entries  .-oming  after 
item  in  the  menu  are  moved  up  one  slot. 

boolean  ciInMenu(menu,  item) 
menutype  ‘menu; 
char  ‘item; 

ctInMenu  returns  TRUE  if  item  is  an  entry  in  the  menu  pointed  to  bv  menu,  otherwise  returns 
FALSE. 

boolean  cilnCurrMenu(item) 
char  ‘item; 

cilnCurrMenu  returns  TRUE  if  item  is  an  entry  in  the  current  menu,  otherwise  returns  F.ALSE. 

int  ciMenuSize(menu) 
menutype  ‘menu; 

ciMenuSize  returns  the  number  of  items  in  the  menu  pointed  to  by  menu.  It  assumes  the  last  item 
in  the  menu  is  followed  by  a  NUXL  entry. 

int  ciPageSize() 

ciPageSize  returns  the  number  of  items  in  the  current  page  of  the  current  menu. 

int  ciMapSlotV2R(virt) 
int  virt; 

ciMapSlotVSR  maps  a  virtual  menu  slot  virt  of  the  menu  structure  to  an  .actual  slot  in  the  menu 
area  of  the  graphics  display  and  returns  the  actual  slot  number. 

int  ciMapSlotR2V(real_slot) 
int  real_slot; 

ciMapSlotR2V  maps  a  real  menu  slot  realjsht  of  the  menu  area  of  the  graphics  display  to  a  virtual 
slot  in  the  menu  structure  and  returns  the  virtual  slot  number. 
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SetTopMenuO 


SetTopMenu  sets  a  flag  that  indicates  the  current  menu  is  'he  rop  command  menu.  This  flag  Ls 
used  for  handling  command  repetition. 

UnsetTopMenuf) 

UnsetTopMenu  unsets  the  flag  indicating  the  current  menu  is  the  top  irommand  menu. 

boolean  IsTopMenu() 

IsTopMenu  returns  the  current  value  of  the  top  menu  flag  whose  value  is  modified  with  Se.tTop- 
Mtnu  and  UnsetTopMenn. 

ciSortMenu(menu,  dontsort) 
menutype  *menu: 
int  dontsort: 

ciSortMe.nu  alphabetically  sorts  part  of  the  menu  pointed  to  by  menu,  leaving  the  first  dontsort 
items  in  their  original  positions. 

PROMPT  AND  HELP  MESSAGES 

ciSetMessages(prompt,  help) 
char  *prompt; 
char  ‘help; 

ciSetMessagee  sets  the  command  interpreter's  prompt  message  to  prompt  and  its  help  message  to 
help.  Pointers  are  set  to  point  to  the  two  strings;  they  aren’t  copied.  Therefore,  if  one  of  the 
strings  passed  to  ciSetMessages  is  changed,  the  corresponding  command  interpreter  message  will 
change. 

ciPrompt() 

ciPrompt  displays  the  current  command  interpreter  prompt  message  on  the  terminal  screen. 

ciHelpMsgO 

ciHelpMsg  displays  the  current  command  interpreter  help  message  on  the  terminal  screen. 

QUEUE  MANAGEMENT 

The  command  interpreter  maintains  both  the  input  token  queue  and  an  au.xiliary  queue.  Each 
queue  is  an  array  of  pointers  to  characters  which  point  to  the  entries  in  the  queue.  The  auxiliary 
queue  is  used  for  macros  with  embedded  parameter  placeholders.  When  a  macro  name  is  encoun¬ 
tered  in  the  input  queue,  its  definition  is  added  to  the  auxiliary  queue.  Then,  tokens  are  taken 
from  the  auxiliary  queue,  with  each  placeholder  being  replaced  by  the  matching  token  from  the 
input  queue  until  the  auxiliary  queue  is  empty. 

ciQueueAdd(token) 
char ‘token; 

ciQueueAdd  adds  the  token  token  to  the  tail  of  the  token  queue.  It  returns  0  upon  normal 
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completion,  -1  if  the  token  queue  is  ilreaciv  full,  and  -2  on  a  memory  allocation  failure. 
r.iQuKueAdd  as.sumes  that  the  length  of  new  token  is  less  than  TOKENLEN  and  that  queue's  rail 
pointer  points  ro  an  empty  slot. 

ciAuxQueueAdd(token) 

char  ’'token: 

ciAuxQueue.Add  adds  the  token  token  to  the  tail  of  the  auxiliar:/  token  queue.  It  returns  0  upon 
normal  completion  and  -2  on  a  memory  allocation  faiiure.  ciAuxQuentAdd  assumes  that  the  length 
of  the  new  token  is  less  than  TOKENLEN  and  that  the  auxiliary  queue's  tail  pointer  points  to  an 
empty  slot. 

ciQueuePushCtoken) 

char  *token; 

ciQueuePush  adds  a  token  to  the  head  of  the  token  queue.  It  returns  0  upon  normal  completion. 
-1  if  the  token  queue  is  already  full,  and  -2  on  a  memory  allocation  failure.  It  assumes  that  the 
length  of  the  new  token  is  less  than  TOKENLEN  and  that  the  queue’s  tail  pointer  points  to  an 
empty  slot. 

int  ciQueueGet(token_val) 
char  token_val[j; 

ciQueueOet  gets  the  next  token  from  the  input  queue  or  the  auxiliary  queue  into  tokenjual  and 
returns  the  token’s  lexical  type.  If  the  value  of  the  flag  H.se_auz_queue  (which  is  set  with 
ciUaeAnxQueue)  is  TRLfE,  it  takes  the  first  token  from  the  auxiliary  queue.  If  this  token  is  a  place 
holder  and  the  token  at  the  front  of  the  input  queue  is  a  DELIM_CHAR,  ciQueueGet  leaves  the 
auxiliary  queue  unchanged  and  gets  a  token  from  the  input  queue  instead.  ciQueueGet  assumes 
that  loken_val  is  at  least  TOKENLEN  +  1  in  length,  that  the  token  at  the  head  of  the  input 
queue  is  non-null  and  is  no  longer  than  TOKENLEN.  and  that  the  input  queue  is  not  empty. 

ciQueueFlush() 

ciQueueFlush  flushes  the  token  queue  and.  if  use_aux_queue  is  TRUE,  flushes  the  auxiliary  queue 
as  well.  When  a  queue  is  flushed,  all  the  tokens  in  it  are  removed  and  its  h“ad  and  tail  pointers 
are  reset  to  zero. 

int  ciQueueSize() 

ciQueueSize  returns  the  number  of  tokens  in  the  token  queue, 
boolean  ciQueueEmpty() 

ciQueueEmpty  returns  F.\LSE  if  the  token  queue  has  any  tokens  or  if  it  is  empty  and  the  auxiliary 
queue  has  a  token  other  than  a  place  holder.  It  returns  TRUE  otherwise. 

boolean  ciQueueFull() 

ciQueueFuU  returns  TRL^E  if  the  token  queue  is  full,  and  F.-VLSE  otherwise. 
ciUseAuxQueue() 

ciUaeAuxQneue  sets  the  flag  uae_aui_qHene,  indicating  that  the  auxiliary  queue  is  to  be  used. 


Appendix  D,  III-ll 


SCRIPT  FILES 


The  command  interpreter  can  reati  commands  from  text  files  called  scri-pt  files,  just  as  it  does  from 
the  keyboard.  Because  a  command  in  one  script  file  can  read  commands  from  another  script  file,  a 
stack  of  script  files  is  maintained. 


chap  '"ciReadScriptO 

ciReadScript  gets  a  line  of  input  from  the  script  file  .at  the  top  of  the  stack,  and  returns  a  pointer 
to  a  static  buffer  containing  the  input  line,  or  NULL  if  end  of  file  was  reached.  It  assumes  that 
the  command  Interpreter  is  currently  in  script  mode. 

ciUseScriptFile(file) 
char  ’'file: 

ciUseScriptFih  opens  the  file  named  file,  and  pushes  the  file  pointer  onto  the  stack  of  script  files. 
It  also  sets  the  flag  indicating  that  the  command  interpreter  is  in  script  mode.  ciUseScriptFile 
returns  -1  if  it  can  not  open  the  script  file. 

boolean  ciInScriptMode{) 

cilnScriptMode  returns  TRUE  if  the  command  interpreter  is  in  script  mode,  F.ALSE  otherwise. 

ciSetScriptFlag(value) 
boolean  value; 

ciSetScriptFlaij  sets  the  flag  indicating  whether  the  command  interpreter  is  in  script  mode  to 
value,  which  should  be  either  TRUE!  or  F,-\LSE. 

Pushltem(fileptr) 

FILE  *fileptr: 

Pushitem  pushes  file  pointer  fileptr  onto  the  dynamically-allocated  stack  of  script  file  pointers. 
PopItem() 

Popltein  pops  the  top  file  pointer  from  the  script  file  stack  and  closes  the  associated  file. 
ciScriptCleanupO 

ciScriplCleanup  closes  all  script  files,  frees  the  memory  associated  with  the  script  file  stack,  issues 
an  error  message,  sets  the  script  error  flag,  and  flushes  the  input  queue. 

TYPES  AND  VALIDATION 

These  routines  are  used  to  determine  the  lexical  types  of  tokens  and  to  validate  them.  Possible 
lexical  types  are  INTEGER,  FLO.\T,  COORDINATE,  IDENTIFIER,  PUNCTUATION,  NEW- 
LINE,  TEXT,  and  DELIM  CHAR. 

int  ciTokenType(token) 

char  *token; 

ciTokenType  returns  the  lexical  type  of  the  token  token,  or  -1  if  its  type  cannot  be  determined. 
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boolean  IsIntType(s) 

register  char  *?: 

IsIntType  returns  TRL^E  if  the  string  s  has  lexical  type  INTEGER  and  F.ALSE  otherv.-ise.  A.  valid 
INTEGER  consists  of  an  optional  sign  followed  by  a  string  of  digits  O.-iH.  it  assumes  ■!  is  not 
NULL  and  does  not  handle  leading  or  trailing  blanks. 

boolean  IsRealTypefs) 

register  char  *s\ 

[sRealType  returns  TRULl  if  the  string  s  has  lexical  type  FLOAT;  otherwise.  F.ALSE.  .A.  valid 
FLOAT  consists  of  an  optional  sign,  a  string  of  digits,  a  decimal  point,  and  another  string  of 
digits.  Either,  but  not  both,  of  the  strings  of  digits  may  be  empty.  isReutTtipe  assumes  >  is  not 
-NULL  and  does  not  handle  leading  or  trailing  blanks. 

boolean  IsCoordType(s) 
register  char  *s; 

IsCoordType  returns  TRUE  if  the  string  s  has  lexical  type  COORDINATE  and  F.VLSE  otherwise. 
.4  valid  COORDINATE  consists  of  a  string  of  digits,  a  comma,  and  a  .-lecond  .string  of  digits. 
IsCoordType  assumes  s  is  not  .NULL  and  does  not  handle  leading  or  trailing  i)lanks. 

boolean  IsIdentType(s) 
register  char  *s: 

IsIdentType  returns  TRUE  if  the  string  -s  has  lexical  type  IDENTEER  and  F.4LSE  otherwise.  A 
valid  IDENTIFER  is  of  the  form  fa-zA-Z'j'a-zA-ZO-O.J*.  IsIdentType  :is.sumes  s  is  not  NILL  and 
does  not  handle  leading  or  trailing  blanks. 

boolean  IsPunctType(s) 
register  char  *s; 

IsPunctType  returns  TRUE  if  the  string  .5  has  lexical  type  PUNCTUATION  and  F.4LSE  otherwise. 
A  valid  PUNCTUATION  string  consists  of  a  single  punctuation  mark. 

boolean  IsNewLineType(s) 
register  char  *s; 

IsNewLineType  returns  TRUE  if  the  string  s  has  lexical  type  NEWLINE,  i.e.  consists  of  a  single 
newline  ("\n"),  and  F,4LSE  otherwise. 

boolean  IsTextType(s) 
register  char  *s; 

IsTextTypc  returns  TRUE  if  the  string  s  has  lexical  type  TEXT.  i.e..  consists  only  of  printable 
characters  or  a  single  newline,  and  F.4LSE  otherwise. 

boolean  IsDelimType(s) 

register  char  *s; 

IsDelimType  returns  TRUE  if  the  string  s  has  lexical  type  DELIM_CIL4R.  i.e..  its  first  character  is 
DELfM_CHAR  (“\r"),  and  FAL.SE  otherwise. 
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int  ciValidateToken(tokenp,  validate,  canon  form) 

tokentype  *tokenp; 
int  (*vaiidate)(); 
int  oanonj'orm; 

ciVaiidattToken  attempts  to  validate  the  token,  token,  based  on  the  canonical  form  'anonjorm 
and  using  the  function  validate,  ft  returns -t  if  the  roken  is  not  valid  and  0  otherwise. 

MISCELLANEOUS  ROUTINES 

DoShell(string) 

char  ‘string; 

DoShell  performs  a  shell  escape  from  the  client  program.  Under  V'MS.  a  .subprocess  is  spawned. 
Under  UNIX,  the  appropriate  shell,  as  determined  by  the  SHELL  environment  variable  (/bin/sh 
is  the  default),  is  invoked.  If  .string  is  not  empty,  it  is  passed  as  a  command  to  the  subprocess 
(VMS)  or  shell  (UNIX). 

char  *stranoc(s) 
char  *3; 

■stralloc  allocates  a  new  string  of  the  appropriate  length  and  copies  .?  into  it.  It  returns  a  pointer  to 
the  new  string,  or  NLTL  if  there  is  a  memory  allocation  failure. 

coordtype  ’*ci_atoc(s) 
char  *s; 

cijiloe  converts  a  string  representation  -s  of  a  coordinate  to  coordtype.  The  string  representation 
must  be  of  the  form  "x,y".  ci_atoc  returns  a  pointer  to  a  static  coordinate  structure  containing 
the  converted  coordinate  if  the  conversion  is  successful  and  NULL  if  it  is  not. 

boolean  cilsNewline(str) 
char  *str; 

cilsNewline  returns  TRLTE  if  the  first  character  of  string  sir  is  the  newline  ("\u")  character  and 
FALSE  otherwise. 
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PART  IV 


ADAS  Editor  Routines 


INTRODUCTION 

The  .\DAS  Editor  (libedit)  contains  the  routines  that  implement  the  .\DAS  editor.  This  editor  is 
used  to  modify  the  values  of  attributes  associated  with  ,\DAS  data  base  components.  The  editor 
does  type  checking  only  on  the  values  entered  by  the  user.  .\ny  other  checking  is  left  to  the  client 
program,  since  different  clients  may  use  a  given  attribute  for  different  purposes. 

EDITING  GRAPH  COMPONENTS 

Several  global  variables  are  used  in  the  ADAS  editor  routines.  The  variables  ned.  aed,  and  ped  are 
the  editor's  current  node,  arc.  and  port.  Routines  accept  a  parameter  that  indicates  which  type  of 
graph  element  is  to  be  edited  (possible  values  are  GRAPH,  NODE,  .ARC,  IN,  and  OUT),  then  they 
use  the  appropriate  global  variable.  The  boolean  variable  tmpflag  is  TRUE  if  values  in  the  tem¬ 
plate  data  base  are  being  edited  and  FALSE  if  the  graph  data  base  is  being  used.  The  boolean 
■•itatflag  is  TRUE  if  attribute  modification  .statuses  are  being  edited  and  FALSE  if  their  values  are 
being  edited. 

Special  editor  control  characters  are  used  to  traverse  the  attribute  list  currently  being  edited.  The 
special  edit  characters  are;  newline  (''\n":  go  to  next  attribute),  minus  sign  go  to  previous 
attribute),  plus  sign  go  to  attribute  list  for  next  port),  tilde  end  the  editing  session), 

sharp  sign  set  this  string  attribute  value  to  the  null  string),  caret  go  to  the  first  attri¬ 
bute  in  the  list),  and  ampersand  display  the  edit  help  message).  Many  routines  return  a 

code  specifying  which  special  character,  if  any,  has  been  entered.  The  valid  editor  return  codes 
are  ED_CURRENT,  ED_NEXT,  ED_PRE\10US.  ED  FIRST,  ED_DONE,  ED_NEXT_PORT,  and 
ED_USE_PREV. 

EditO 

Edit  is  the  top-level  routine  for  the  edit  command.  It  accepts  the  top-level  edit  menu  selection 
and  invokes  the  appropriate  editing  procedure. 

int  EditGraph() 

EditGraph  allows  the  user  to  edit  graph  attributes  for  the  current  graph. 

EditNode(n) 

nodetype  n; 

EditNode  allows  the  user  to  edit  the  attributes  of  a  node.  If  n  is  NUIA,  the  node  is  selected  by  the 
user;  otherwise,  the  node  n  is  edited.  If  n  is  not  NUT.L,  it  is  assumed  to  be  a  valid  node.  EditNode 
sets  the  global  variable  ned  to  n. 

EditBus(b) 

bustype  b; 

EditBus  allows  the  user  to  edit  the  attributes  of  a  bus.  If  b  is  NULL,  the  bus  is  selected  by  the 
user;  otherwise,  the  bus  b  is  edited.  If  b  is  not  NUTL,  it  is  assumed  to  be  a  valid  bus.  EditBus  sets 
the  global  variable  bed  to  b. 
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EditArc(a) 

arctype  a: 

SdilArc  allows  r,he  user  ro  edic  rlie  attribuces  of  an  arc.  If  a  is  NLILL.  the  arc  is  selected  by  the 
user;  otherwise.  r,he  arc  a  is  edited.  If  a  is  not  .NULL,  it  is  assumed  to  be  a  valid  arc.  EditArc  sets 
the  global  variable  ae-d  to  a. 

EditNodeTmp() 

EditNodeTmp  allows  the  user  to  edit  a  node  template.  The  user  is  prompted  for  the  template 
name. 

EditArcTmpO 

EditArcTmp  allows  the  user  to  edit  an  arc  template.  The  user  is  prompted  for  the  arc  template 
name. 

EditBusTmpO 

EditBusTmp  allows  the  user  to  edit  an  bus  template.  The  user  is  prompted  for  the  bus  template 
name. 

EditRepeat(naflag) 
int  naflag; 

EditRepeat  allows  the  user  to  re-edit  the  attributes  for  the  selected  graph  element.  When  the  user 
exits  the  editor,  he  is  given  the  option  of  re-editing  the  item.  The  graph  element  type  is  indicated 
by  naflag. 

DoEdlt(naflag) 
int  naflag; 

DoEdit  steps  through  the  list  of  attributes  for  the  graph  element  type,  indicated  by  naflag,  until 
done.  The  edit  is  completed  when  the  entire  list  has  been  traversed,  CANCEL  has  been  received, 
or  the  user  has  entered  the  ED_DONE  character. 

int  NextPort(n,  naflag) 

int  n; 
int  naflag; 

NextPort  advances  the  editor  to  the  attribute  list  for  the  next  port  when  editing  a  node.  The 
integer  n  is  the  current  (old)  attribute  number  and  naflag  indicates  the  graph  element  type  being 
edited.  This  routine  is  called  when  ED_NEXT_PORT  is  received.  NextPort  returns  the  index  of 
the  next  port  or  the  last  attribute.  It  assumes  that  naflag  is  GRAPH,  NODE,  or  ARC. 

EdHelpO 

EdHelp  displays  information  concerning  editing  attribute  values  on  the  terminal  screen. 

boolean  SpecialChar(str) 

char  *str; 

SpecialChar  returns  TRUE  if  str  points  to  a  special  edit  character,  and  F-M^SE  otherwise. 
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boolean  NodeSpecialChar(str) 
char  *str; 

NodeSpecialChar  returns  TRUE  if  str  is  the  name  of  a  node  or  points  to  a  sneciai  •■uit  ciiaracter. 
and  FALSE  otherwise. 

boolean  BusSpecialChar(str) 
char  *str; 

BusSpecialChar  returns  TRLTI  if  str  is  the  name  of  a  bus  or  points  to  a  special  edit  <  har:icter.  and 
FALSE  otherwise. 

boolean  NodeBusSpecialChar(str) 
char  *str; 

NodeBusSpecialChar  returns  TRUE  if  str  is  the  name  of  a  node  or  bus  or  points  to  a  special  edit 
character,  and  FALSE  otherwise. 

EDIT  SELECT 

EditSelect() 

EditSelect  allows  the  user  to  edit  a  selected  attribute  for  a  chosen  element  type.  The  user  selects 
the  element  type  from  a  menu,  then  specifies  whether  to  edit  all  items  of  that  type  or  to  select  the 
particular  items  to  edit  by  name. 

EditSelectTmp(napflag,  select_all) 
int  napflag; 
int  select_all; 

EditSelectTmp  sets  the  global  template  flag  tmpflag  in  order  to  use  the  template  data  base,  then 
calls  procedure  EditSdeclNAP  —  the  same  routine  used  for  non-template  select  editing. 

EditSelectNAP(napf!a.g,  sclect_all) 
int  napflag; 
int  select_all; 

EditSelectNAP  carries  out  selective  editing  for  either  nodes,  arcs,  or  node  ports.  The  value  of  nap¬ 
flag  determines  which  object  type  is  being  edited.  Valid  values  for  napflag  are  .XODE.  .ARC.  IN. 
and  OUT.  If  select_all  is  TRUE,  the  selected  attribute  is  edited  for  all  objects  of  this  type;  other¬ 
wise,  the  individual  objects  are  selected  by  name,  statflag  is  checked  to  see  if  attribute  modifica¬ 
tion  statuses  are  being  edited,  and  tmpflag  is  checked  to  determine  if  the  template  data  base  is 
being  used. 

EditSeIectAlI(napfIag,  att  name) 
int  napflag; 
char  *att_name; 

EditSelectAII  allows  the  user  to  edit  the  attribute  with  name  alt_name  for  all  instances  of  the  type 
of  graph  element  type  indicated  by  napflag. 
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EditSelectAtt(napflag,  att  name,  name) 

int  napflag; 
char  *att_aanie; 
char  *name; 

EditSelectAtt  prompts  the  user  for  the  aame  nmne  of  the  graph  eiemenr,  of  type  napflag  for  wiiich 
he  wishes  to  edit  the  attribute  attjaamt. 

EditSelectByName(napflag,  att  name) 
int  napflag; 
char  *att_name; 

EditSelectByName  displays  the  full  list  of  graph  items  of  the  type  indicated  by  napflag.  The  user 
selects  one  item,  has  a  chance  to  change  the  value  of  the  attribute  attjiamt.  and  then  may  select 
a  new  item  to  edit. 

EDIT  GLOBAL 

EditGlobalO 

EditGlobal  allows  the  user  to  select  the  graph  element  type  for  the  global  edit.  Global  editing 
allows  the  user  to  set  the  value  of  one  attribute  to  a  particular  value  for  all  e.xisting  graph  ele¬ 
ments  derived  from  a  given  template;  additionally,  it  optionally  saves  the  new  value  in  the  tem¬ 
plate. 

EditGlobalNAP(napflag) 
int  napflag; 

EditGlobalNAP  displays  the  attribute  list  for  the  previously  selected  graph  type  indicated  by  nap¬ 
flag.  The  user  selects  the  attribute  for  the  global  edit.  The  global  variable  -statflag  is  used  to 
determine  which  attributes  to  display.  Some  node  and  arc  attributes  do  not  have  modifiable  sta¬ 
tuses. 

EditGlobalAtt(napflag,  att_name) 

int  napflag; 
char  *att_name; 

EditGlobalAtt  allows  the  user  to  do  global  editing  of  the  attribute  altjiame  for  the  graph  element 
type  indicated  by  napflag.  First,  the  user  selects  the  template  for  the  global  edit  and  enters  the 
new  attribute  value;  he  is  given  the  option  of  saving  the  change  in  the  template  itself,  then  DoGlo- 
balEdit  is  called  to  set  the  attribute  value  for  all  graph  elements  derived  from  the  chosen  template. 

DoGlobalEdit(napflag,  name,  att_name) 

int  napflag; 
char  ‘name; 
char  *att_name; 

DoGlobalEdit  goes  through  the  data  base  and  sets  the  value  of  attribute  att_name  for  all  items  of 
the  type  indicated  by  napflag,  derived  from  template  name,  to  agree  with  the  template’s  value  of 
that  attribute. 
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CHANGING  ATTRIBUTE  VALUES 


EditAtt(type.  att) 
ini  type; 
inc  alt: 

EditAtt  allows  the  user  to  edit  attribute  number  ut  of  the  current  element  of  type  type  (GR.\PH. 
NODE.  ARC.  IN,  or  OUT).  The  current  value  of  the  attribute  is  displayed,  and  the  user  is  given  a 
chance  to  enter  a  new  value  if  the  attribute  is  modifiable.  EditAtt  returns  one  of  the  edit  return 
codes. 

EdSetAtt(type,  att,  val) 
int  type: 
int  att: 
char  *val: 

EdSetAtt  sets  the  value  of  attribute  number  att  of  the  current  element  of  type  type  to  val. 
EdSetAtt  assumes  that  att  is  a  valid  attribute. 

char  *EdGetAtt(type,  att) 
int  type; 
int  att: 

EdGetAtt  returns  a  pointer  to  the  string  representation  of  the  value  of  attribute  number  att  of  ele¬ 
ment  type  type.  If  the  type  is  not  GRAPH,  one  or  more  of  the  global  variables  ned,  aed.  and  ped 
will  determine  the  correct  element.  EdGetAtt  assumes  that  att  is  a  valid  attribute. 

char  *EdGetAttName(type,  att) 
int  type; 
int  att; 

EdGetAttName  returns  the  name  of  attribute  att  of  graph  element  type  type. 

int  GetAttIndex(type,attname) 

int  type; 

char  *attname; 

GetAttIndex  returns  the  index  of  the  attribute  of  graph  element  type  type  with  name  atlname.  It 
assumes  type  is  one  of  GRAPH,  NODE.  .ARC,  IN,  or  OUT. 

boolean  EdAttMap(n,  naflag,  att,  type,  port) 

int  n; 

int  naflag; 

int  *att; 

int  ‘type; 

int  ‘port; 

EdAttMap  maps  the  attribute  number  n  for  the  graph  element  type  given  by  naflag  (GR.APH, 
NODE,  ARC,  PARTITION,  or  BUS)  to  the  appropriate  attribute  index  for  that  type.  The 
integers  pointed  to  by  att,  type,  and  port  are  set  to  the  adjusted  attribute  index,  the  graph  ele¬ 
ment  type  (GRAPH,  NODE,  .ARC,  P.ARTITION,  BUS,  IN,  OUT.  or  BI),  and  the  port  number. 
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respectively.  The  value  of  utt  is  adjusted  For  special  attributes  that  do  not  appear  in  the  attribute 
list.  e.g.  node_namt.  EdAttMap  returns  TRUE  if  there  are  no  more  attributes  to  edit.  i.e..  n 
exceeds  the  attribute  index  range  for  the  graph  element  type. 

char  *AttPrompc(  label,  val) 

char  *labei: 
char  *val; 

AttPrompt  builds  and  returns  a  pointer  to  the  prompt  for  the  attribute  with  name  label  and 
current  value  uai.  The  prompt  is  built  in  a  .static  buffer  which  is  overwritten  by  the  next  call  to 
AttPrompt. 

boolean  DisplayedAtt(type,att) 

int  type: 
int  att: 

DisplayedAtt  determines  whether  attribute  att  of  graph  element  type  type  affects  the  appearance 
of  the  graphics  display,  e.g.,  nodejiolor.  It  returns  TRLIE  if  att  affects  the  screen  and  FALSE  oth¬ 
erwise. 

MODIFICATION  STATUSES 

A  modification  status  is  associated  with  each  attribute,  in  addition  to  the  attribute’s  value.  .An 
attribute’s  modification  status  determines  the  means  by  which  its  value  can  be  changed.  Valid 
modification  statuses  are  M  (MODIFY),  P  (PROGMODIFY),  N  (NOMODIFY),  and  U 
(NOTUSED).  An  attribute  with  status  M  can  be  modified  by  the  user  with  the  editor.  Status  P 
indicates  that  an  attribute  can  be  modified  only  by  an  .ADAS  program,  not  directly  by  the  user. 
•An  N  modification  status  means  the  attribute  is  unmodifiable.  An  attribute  with  U  status  is 
marked  as  not  used. 

EditStats() 

EditStats  allows  the  user  to  edit  the  modification  statuses  of  attributes.  EditStats  operates  like  the 
top-level  Edit  routine,  after  first  setting  the  global  flag  statflag  to  indicate  that  statuses  are  being 
edited,  rather  than  attribute  values. 

EditAttStat(type,  att) 

int  type; 
int  att; 

EditAttStat  allows  the  user  to  edit  the  attribute  modification  status  of  attribute  number  att  of  the 
current  element  of  type  type.  The  current  status  is  displayed  and  the  user  is  given  a  chance  to 
enter  a  new  modification  status.  EditAttStat  returns  one  of  the  edit  return  codes. 

EdSetAttStat(type,  att,  s) 
int  type; 
int  att; 
char  *s; 

EdSetAttStat  sets  the  modification  status  of  attribute  number  att,  of  the  current  element  of  type 
type,  to  the  status  indicated  by  the  character  pointed  to  by  .s  ("M“,  "P",  or  "U"). 

EdSetAttStat  assumes  att  is  a  valid  attribute  index. 
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int  EdGetAttStat(type,  att) 

int  type: 
int  att; 

EdGetAttStat  returns  the  modification  status  of  attribute  number  .itt  of  ihe  current  ^rapii  element 
of  type  type.  It  assumes  att  is  a  valid  attribute  index. 

EdSetAttStatInt(type,  att,  stat) 
int  type; 
int  att; 
int  stat; 

EdSetAttStatInt  sets  the  modification  status  of  attribute  number  att  of  the  current  element  of  type 
type  to  status  ■■itat.  EdSetAttStatInt  does  the  same  thing  as  EdSetAttStat.  except  it  uses  the  integer 
modification  status  instead  of  a  character  code  which  represents  the  new  status. 

EdGetUserModStat(type,att) 
int  type; 
int  att; 

EdGetUserModStat  returns  the  modification  status  of  attril)ute  att  for  the  element  of  type  type 
currently  being  edited. 

EdStatHelpO 

EdSlatHelp  displays  information  concerning  editing  attribute  modification  statuses  on  the  terminal 
screen. 

char  '''AttStatPrompt(label,  stat) 
char  *label; 
int  stat; 

AttStatPrompt  builds  and  returns  a  pointer  to  the  prompt  for  the  modification  status  of  the  attri¬ 
bute  with  name  label  and  current  modification  status  stat.  The  prompt  is  built  in  a  static  buffer 
which  is  overwritten  by  the  next  call  to  AttStatPrompt. 

boolean  IsValidStat(str) 
char  *str; 

hValidStat  returns  TRUE  if  str  is  a  valid  status  name  or  points  to  a  special  edit  character,  and 
FALSE  otherwise. 

ATTRIBUTE  SAVE  STATUS 

Not  every  ADAS  data  base  contains  the  full  set  of  attributes  for  all  graph  element  types.  The  user 
can  select  which  attributes  to  save  to  a  data  base  file  by  editing  attribute  save  status.  .An 
attribute’s  save  status  is  either  S,  meaning  it  will  be  saved  to  the  data  base  file,  or  N,  meaning  it 
will  not.  The  following  editor  routines  are  used  for  editing  attribute  save  status. 

EditSaveStats(allflag) 

boolean  allflag; 

EditSaveStats  allows  the  user  to  edit  the  save  status  for  attributes  of  any  object  type.  It  provides 


Appendix  D,  rV-7 


a  menu  from  which  the  user  selects  an  object  type  or  ailatta.  By  choosing  the  aser  'an  -^et 

all  attributes  of  an  object  type  to  be  either  savaole  or  unsavable.  The  idflmj  parainerer-  ru 
EditSaueStats  is  TRUE  if  it  is  recursiveiy  called  to  handle  an  ailatts  selection . 

Edit3aveAnStats(element.  attcount,  tmpflag) 
int  element: 
int  attcount: 
boolean  tmpflag; 

Edits  ave  Alls  tats  allows  the  user  to  set  the  save  status  for  all  attributes  of  graph  element  type  e/'e- 
ment  to  either  S  or  N.  The  value  of  attcount  is  the  total  number  of  attribtiies  for  tne  'dement 
type,  and  tmpjlag  is  TRUE  if  the  desired  element  type  is  a  template  type. 

EditRepeatSave(naflag,  att_count) 
int  naflag; 
int  att_count; 

EditRepeatSave  allows  the  user  to  re-edit  the  save  .status  of  attributes  for  graph  element  type 
naflag.  When  the  user  exits  the  editor,  he  is  given  tne  iiption  of  re-editing  the  item.  The  total 
number  of  attributes  for  the  graph  element  type  is  given  by  attj;oant. 

EditSaveAtts(eflag,  att_count) 

mt  eflag: 

int  att_count; 

EditSaveAtts  allows  the  user  to  set  the  save  status  for  the  attributes  of  rhe  element  type  given  by 
eflag.  It  steps  through  all  att_count  attributes,  and  the  user  can  enter  a  new  save  status  for  each. 

EditSaveAtt(type,  att) 
int  type; 
int  att; 

EditSaveAtt  allows  the  user  to  set  the  attribute  save  status  for  attribute  att  of  element  type  type 

EditSaveT mpl Atts(eflag,  att_count) 

int  eflag; 

int  att_count; 

EditSaveTmplAtts  sets  the  current  data  base  to  the  template  data  base  in  preparation  for  editing 
the  save  status  for  attributes  of  element  type  eflag.  The  number  of  attributes  for  the  element  type 
is  given  by  attjeount.  EditSaveTmplAtts  sets  up  the  template  data  base,  then  calls  Edi- 
iRepeatSave  to  do  the  attribute  save  status  editing. 

boolean  IsValidSaveStat(str) 

char  *str; 

hValidSaveStat  returns  TRUE  if  str  points  to  a  valid  attribute  save  status  or  a  special  edit  charac¬ 
ter,  and  FALSE  otherwise. 

EdSaveStatHelpO 

EdStatHelp  displays  information  concerning  editing  attribute  save  statuses  on  the  terminal  screen. 
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SELECTING  GRAPH  ELEMENTS  FOR  EDITING 


EdSetNode(node.  template,  ptype,  pstatus) 

nodet.ype  'node; 
boolean  Template; 

Int  ptype; 
int  pstat'.is; 

EdSf.tNode  displays  a  menu  of  nodes  in  the  eurrent  ^raph.  prompts  the  user  for  a  node,  and  sets 
node  to  point  to  the  selected  node.  If  te.mvlate,  is  TRI.fE.  i  node  template  is  wanted  and  the  menu 
will  contain  node  temniate  names.  The  ptype  .and  pxtatns  parameters  determine  which  nodes  are 
included.  The  value  of  pstatus  is  0  it  onlv  nodes  with  unoccupied  ports  are  to  be  added.  1  for  only 
nodes  with  occupied  ports,  and  2  for  ail  nodes.  The  value  of  ptype  is  interpreted  as  a  bit  vector 
flagging  the  types  of  port.s  to  ne  considered  in  this  decision.  The  least  significant  bit  is  set  for 
inports,  the  next  for  outports.  and  rhe  third  for  biports.  If  pstatus  is  set  to  3,  all  nodes  with  ports 
of  the  type(s)  indicated  by  ptype  will  be  included,  regardless  of  whether  or  not  the  ports  are  occu¬ 
pied. 

EdSetBus(bus,  template) 

bustype  *bus; 
boolean  template; 

EdSetBus  displays  a  menu  of  the  buses  in  the  current  graph,  prompts  the  user  for  a  bus.  and  sets 
bus  to  point  to  the  selected  bus.  If  template  is  TRUE,  a  bus  template  is  wanted,  so  the  menu  con¬ 
tains  bus  template  names. 

EdSetArcTmp(arc) 

arctype  *arc; 

EdSetArcTmp  creates  a  menu  of  arc  names  from  the  current  graph  and  allows  the  user  to  select  an 
arc.  The  variable  arc  is  then  set  to  point  to  this  arc.  EdSetArcTmp  returns  an  editor  return  code, 
e.g.,  ED_DONE. 

EdSetPort(port_type,  occ,  ioflag,  port) 

int  port_type; 

int  occ; 

int  'ioflag; 

int  'port; 

EdSetPort  prompts  the  user  for  a  port  on  ned,  the  node  currently  being  edited.  The  value  of 
port_type  is  interpreted  as  a  bit  vector  whose  bits  .are  set  to  indicate  which  port  types  should  be 
included  in  the  menu  where  the  user  makes  his  selection.  The  least  significant  bit  is  for  inports, 
the  next  for  outports.  and  the  third  for  biports.  The  value  of  occ  should  be  0  for  only  the  unoccu¬ 
pied  ports  to  be  included  in  the  menu,  1  for  only  occupied  ports,  and  2  for  both.  The  integer 
pointed  to  by  ioflag  is  set  to  the  type  of  port  selected  (IN,  OUT,  or  BI)  and  the  integer  pointed  to 
by  port  is  set  to  the  index  of  the  selected  port.  EdSetPort  returns  an  editor  return  code,  e.g.. 
ED_DONE. 

EdSetArcNode(node) 

nodetype  'node; 

EdSetArcNode  creates  a  menu  of  nodes  to  which  arcs  are  attached  and  allows  the  user  to  select  a 
node.  The  node  pointed  to  by  node  is  set  to  the  selected  node. 
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PART  V 


ADAS  Graphics  Interface  Routines 


INTRODUCTION 

The  ADAS  Graphics  Interface  (libgraphics)  provides  a  device-independent  interface  for  ADAS  pro¬ 
grams.  It  hides  the  device-dependent  details  of  the  graphics  system  '.vhich  ire  isoiated  m  ihe 
Graphics  Package  (libgp). 

INITIALIZING  AND  TERMINATING  GRAPHICS 

GIInitializeDisplay(disp,  llbdir,  configdir) 
char  *disp; 
char  *libdir; 
char  ‘configdir; 

GIInitializeDisplay  initializes  the  graphics  display  and  the  tablet  of  workstation  setting  the 

window  and  viewport  to  appropriate  startup  values.  The  .AD.AS  library  directory  to  i)e  used  is  lib- 
dir  and  the  configuration  directory  is  configdir. 

GITerminateDisplayO 

GITerminateDisplay  shuts  down  the  graphics  display. 

COORDINATE  SYSTEMS,  VIEWPORTS,  AND  WINDOWS 

The  ADAS  graphics  interface  operates  in  terms  of  two  types  of  coortlinate  systems.  .Xormalizcd 
Device  Coordinates  (NDC)  are  used  to  specify  screen  locations  with  respect  to  the  entire  graphics 
display.  They  range  from  (0.0,  0.0)  at  the  lower  left  corner  of  the  screen,  to  (1.0,  1.0)  at  the  upper 
right  corner  of  the  screen.  Viewports  are  regions  of  the  display  screen  defined  in  fhe  NDC  system. 
A  client  of  the  graphics  interface  might  define  two  viewports:  for  example,  one  for  displaying 
ADAS  graphs  and  the  other  for  menus.  .Associated  with  each  viewport  is  a  window.  Items  drawn 
in  a  window  appear  on  the  screen  in  the  associated  viewport.  World  or  Windoiv  coordinates  (WC) 
are  used  to  refer  to  locations  within  a  window.  When  a  client  defines  a  window,  he  specifies  the 
range  of  coordinates  for  that  window. 

GIAskWindo'w(xniin,  ymin,  xmax,  ymax) 

int  *xmin,  *ymin,  *xmax,  *ymax; 

GIAskWindow  gets  the  coordinates  of  the  lower  left  (xmin.  ymin)  and  upper  right  (.rmiix.  ymai] 
corners  of  the  current  window  in  window  coordinates. 

GISetWindow(xmin,  ymin,  xmax,  ymax) 

int  xmin,  ymin,  xmax,  ymax; 

GISetWindow  sets  the  current  window,  with  the  lower  left  corner  {xmin.  ymin)  and  upper  right 
corner  at  (xmax,  ymax)  given  in  the  window  coordinates. 

GIGetGraphWindow(xmin,  ymin,  xmax,  ymax) 

int  *xmin,  *ymin,  *xmax,  *ymax; 
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GIGetGraphWindow  ^ets  the  coordinates  of  the  lower  left  [smin.  :jmin)  ma  apper  right  iimai. 
ymax)  corners  of  the  graph  window  in  wdndow  coordinates. 

GISetGraphWindowfxmin,  ymin,  xmax,  ymax) 
int  xmin,  ymin,  xmax,  ymax: 

GISetGraphWindo w  sets  the  graph  window  with  the  lower  left  corner  [  ximn.  ymrni  and  upper  right 
corner  (xmax,  ymax)  given  in  window  coordinates. 

GISetViewport(xmin,  ymin,  xmax,  ymax) 
double  xmin,  ymin,  xmax,  ymax; 

GISetViewport  sets  the  current  viewport,  with  its  lower  left  corner  at  i  xmm.  ymin)  and  its  upper 
right  corner  at  (xmax,  ymax]  (NDC). 

boolean  GIInWindow(x,  y) 

int  X,  y; 

GllnWindow  returns  TRUE  if  the  point  (x,  y)  is  within  the  current  window. 

boolean  GIInVicwport(x,  y) 
double  X,  y; 

GllnViewport  returns  TRUE  if  the  point  (x.  y)  is  within  the  current  viewport. 

GIResetGraphWindowO 

GIReeetGraphWindow  sets  the  graph  window  to  include  the  whole  grapli. 

GlUseWVP(w) 
int  w; 

GlUseWVP  makes  the  window  w  and  its  corresponding  viewport  the  current  ones. 

DRAWING  GRAPH  ELEMENTS 

The  following  routines  are  used  to  draw  .ADAS  graph  elements  on  the  graphics  display. 

GIDra'wArc(a,  eflag) 

arctype  a; 
int  eflag; 

GIDrawArc  draws  the  arc  a.  If  eflag  is  nonzero,  then  the  arc  is  drawn  in  the  special  ER.ASE  color, 
meaning  it  is  erased. 

GIDrawPartiaIArc(a,  eflag) 

arctype  a; 
int  eflag; 

GIDrawPartialArc  draws  all  of  arc  a  except  for  the  segment  from  the  last  joint  (or  source  if  there 
are  no  joints)  to  the  sink.  If  eflag  is  nonzero,  that  part  of  the  arc  is  erased  instead. 
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GIDrawNode(n,  eflag,  fillcolor,  outline) 

nodetype  n; 
int  eflag: 
inc  fillcolor; 
int  outline: 

GIDrawNode  draws  the  node  n.  If  tfiag  is  nonzero,  then  the  node  is  drawn  in  the  special  ERASE 
color,  i.e.,  it  is  erased.  If  fillcolor  is  nonzero  it  is  used  as  the  node  color  index  and  outline  is  used 
as  the  outline  color  index.  Otherwise  the  node  color  is  determined  by  the  current  node  drawing 
style. 


GIDrawBusIb,  eflag) 

bustype  b; 
int  eflag; 

GIDrawBns  draws  the  bus  b.  If  ejlaij  is  nonzero,  then  the  bus  is  drawn  in  the  special  ERASE  color, 
i.e.,  it  is  erased. 

GIDrawJunction(b,  j,  eflag) 

bustype  b; 
int  j; 
int  eflag; 

GIDrawJunction  draws  junction  j  of  bus  6.  If  eflag  is  nonzero,  then  the  junction  is  drawn  in  the 
special  ERASE  color,  i.e.,  it  is  erased. 

GIDra'wNodePorts(n,  eflag) 
nodetype  n; 
int  eflag; 

GIDrawNodePorts  draws  the  ports  for  node  n.  If  eflag  is  nonzero,  the  ports  are  erased  instead. 

THE  CONTEXT  WINDOW 

The  ADAS  context  window  displays  the  parent  graph  of  the  current  graph  with  the  parent  node 
highlighted. 

GIDra  vContext() 

GIDrawConleit  draws  the  ADAS  context  window. 

boolean  GIDrawingContext() 

GIDrawingContext  returns  TRLTi  if  the  context  window  is  being  drawn,  and  F.ALSE  otherwise. 
This  routine  is  provided  so  that  other  routines  can  determine  whetlier  they  are  drawing  in  the  con¬ 
text  window. 

boolean  GllsContextParent(n) 

nodetype  n; 

GllsContextParent  returns  TRUE  if  node  n  is  the  parent  node  of  tlie  current  graph,  and  F.ALSE 
otherw^e. 
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GISetContext Window! xi,  yl,  x2,  y2) 

inc  ::L.  yl.  .\2.  y2; 
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GISetContextWindow  sets  the  context  window  corners  at  ixl.  'jl\  and  ij;'.  //J),  'iven  in  wmaow 
coordinates.  The  context  window  is  defined  in  terms  of  the  graph  window  coordmates. 

DRAWING  GRAPH  ELEMENT  LABELS 

The  following  routines  are  used  to  draw  labels  for  .\DAS  graph  elements. 

GIDrawNodeLabel(n,  eflag) 
nodetype  n; 
int  eflag; 

GIDrawNodeLabel  displays  the  label  for  node  n.  If  f./lag  is  nonzero,  the  label  is  erased  inste.ad. 

GIDra'wBusLabel(b,  eflag) 
bustype  b; 
int  eflag; 

GIDrawBusLabel  displays  the  label  for  bus  6.  If  eflag  is  nonzero,  the  label  is  erased  instead. 

GIDrawJunctionLabel(b,  j,  eflag) 

bustype  b; 
int  j; 
int  eflag; 

GIDraivBusLabel  displays  the  label  for  junction  j  of  bus  b.  If  eflag  is  nonzero,  the  label  is  erased 
instead. 

boolean  GILabelsVisible(etype) 
int  etype; 

GILabeUVmble  returns  TRUE  if  labels  for  element  type  etype  are  currently  turned  on. 

REDRAWING  A  GRAPH 

The  following  routines  are  used  to  redraw  an  ADAS  graph  or  a  subset  of  the  elements  of  the 
graph. 

GIRedrawScreen() 

GIRedraxvScreen  erases  and  redraws  the  whole  graphics  image. 

GIRedrawNodes() 

GIRedratvNodes  redraws  all  the  nodes  in  the  graph. 

GIRedrawArcs() 

GIRedrawArcs  redraws  all  the  arcs  in  the  graph. 

GIRedrawBuses() 

GIRedrawBuse-'i  redraws  all  the  buses  in  the  graph. 
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GIRedrawLabels() 

GIRedrawLahf.is  redraws  ail  rhe  node  labels  in  the  ^rapli.  Labels  lor  other  ^raoii  •dements  are 
drawn  when  the  elements  themselves  are  drawn. 

GIRedrawPorts() 

GIRedrawPorts  redraw.s  all  the  node  ports  in  the  'trapii. 

DISPLAYING  TEXT 

The  following  routines  are  used  to  draw  text  on  the  graphics  display. 

GICenterText(s,  x,  y,  color) 
char  *3; 
int  X.  y; 
int  color; 

GICenterText  draws  the  string  pointed  to  by  s  in  color  color  at  the  location  (r.  y)  [WC)  in  the 
current  window. 

GILeftText(s,  x,  y,  color) 
char  *s; 
int  X,  y; 
int  color; 

GlLeftText  displays  the  text  string  pointed  to  by  -s,  left-justified  at  location  (j.  y)  (WC)  in  color 
color. 

GIRightText(s,  x,  y,  color) 
char  *s; 
int  X,  y; 
int  color; 

GIRightText  displays  the  text  string  pointed  to  by  -5.  right-justified  at  location  (jt.  y)  (WC)  in  color 
color.  The  text  is  centered  with  respect  to  the  given  y  coordinate. 

GlSetWCCharWidth(cw) 

float  cw; 

GISetWCCharWidth  sets  the  text  character  width  to  cxv. 

GIRotateText(on) 

boolean  on; 

GlRolaleText  turns  on  text  rotating  if  on  is  TRUE,  and  turns  it  off  otherwise.  When  text  rotating 
is  on,  text  is  displayed  in  an  orientation  rotated  90  degrees  from  the  default  orientation. 

GILandscapeMode(on) 

boolean  on; 

GILand.scapeAfode  turns  landscape  mode  on  if  on  is  TRLi^E,  and  turns  it  off  otherwise.  When  in 
landscape  mode,  the  graphics  coordinate  system  is  rotated  90  degrees  counterclockwise  front  its 
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default  orientation.  Landscape  mode  .must  be  turned  on  before  rotated  text  is  displayed. 

BASIC  DRAWING  OPERATIONS 

The  following  routines  are  used  to  do  basic  drawing  operations.  They  are  “lower  level"  routines 
than  those  for  drawing  .\DAS  graph  elements. 

GIErase() 

GIErase  erases  the  graphics  display  by  filling  it  with  the  special  ERASE  color. 

GIDrawLine(xmin,  ymin,  xmax.  ymax.  color) 
int  xmin,  ymin,  xmax.  ymax: 
int  color: 

GIDrawLint  draws  a  line  from  \ZTntn.  jmin)  to  {xma-z.  ’jvtax)  (WC)  in  the  color  color. 

GIDrawRect(color,  llx,  lly,  iirx,  ury,  fill) 
int  color: 

int  llx.  lly.  urx.  ury; 
boolean  fill: 

GIDrawReci  draws  a  rectangle  with  lower  left  corner  illx.  lly)  and  upper  right  corner  (un.  ury) 
(WC)  in  the  color  color.  If  fill  is  TREE,  a  filled  rectangle  is  drawn:  otherwise  the  rectangle  is 
unfilled. 

MAKING  HARDCOPIES 

These  routines  are  used  for  making  a  hardcopy  of  an  .ADAS  graph. 

GIHardcopy(harddev) 

char  *harddev: 

GIHardcopy  makes  a  hardcopy  of  the  current  graph  using  hardcopy  device  harddcv. 

boolean  GIInHardcopy() 

GIInHardcopy  returns  TRL'E  if  the  current  process  is  a  child  which  was  forked  off  to  do  a  hard¬ 
copy. 

NODE  LATENCY  RANGE 
GISetLatencyRange() 

GISetLatencyRange  sets  the  minimum  and  maximum  latencies  for  normalization.  GISelLaUn- 
cyRange  examines  the  latencies  for  all  nodes  and  sets  the  minimum  and  maximum  internally. 
They  can  be  retrieved  with  GIGetLatencyRange. 

GIGetLatencyRange(Imin,  Imax) 
double  *lmin,  *lmax; 

GIGetLatencyRange  gets  the  minimum  {Imin)  and  maximum  (Imax)  latency  values  for  normaliza¬ 
tion. 
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NODE  AND  ARC  STYLES 


Normally  aodes  and  arc3;,Are  drawn  in  the  colors  given  by  their  color  attributes.  By  setting  the 
node  or  arc  style,  .they  ein  be  drawn  in  colors  reflecting  the  values  of  certain  other  attributes. 

int  GISetNodeStyle(style) 

int  style; 

GISetNodeStyle  sets  the  node  style  to  styie.  specifying  how  node  color  is  determined.  A  node  is 
displayed  either  according  to  its  node_color  attribute  (DFLT_STYLE),  with  a  heated  object  scale 
based  on  either  utilization  (NUTIL)  or  latency! NLATENCY),  or  according  to  its  status 
(NSTATTJS).  When  the  node  style  is  NSTATUS.  nodes  primed  during  simulation  are  drawn  as 
unfilled  rectangles,  while  others  .are  shown  in  DFLT_.STYLE.  GIGetNodeStyle  returns  the  previ¬ 
ous  node  style  value. 

int  GISetArcStylefscyle) 

int  style: 
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GISetArcStyle  sets  the  arc  style  to  style,  specifying  how  arc  colors  are  letermined.  Arcs  fiiay  he 
drawn  according  to  the  arc_color  attribute  iDFLT_STYLE)  or  using  a  heated  oiijecr  -caie.  ;n 
which  an  arc’s  queue  size  determines  its  color  ( ACURR_SIZE).  GISetArcStyie  returns  'he  iirevious 
value  of  the  arc  style. 

int  GISetLabelStyle(style) 
int  style; 

GISetLabelStyle  sets  the  node  label  style  to  style.  The  label  stvle  determines  whetiier  i  node's 
label  corresponds  to  its  nodejname  attribute  (DFLT_STYLE)  or  its  hardwarejnnditle.  attribute 
(NMODULE).  GISetLabelStyle  returns  the  previous  value  of  the  node  label  style. 

SETTING  THE  QUEUE  SCALE 

GISetQueueLB(lb) 
int  lb; 

GISetQueueLB  sets  the  lower  bound  of  user-defined  queue  scale  to  lb. 

GISetQueueUB(ub) 

int  ub; 

GISetQueueUB  sets  the  upper  bound  of  user-defined  queue  scale  to  ab. 

DETERMINING  NODE  DIMENSIONS 

double  GINodeHeight(n) 

nodetype  n; 

GIGetNodeHeight  returns  the  height  of  the  node  n.  This  is  the  value  of  the  node_height  attri¬ 
bute,  which  is  in  ADAS  grid  coordinates. 

double  GINodeWidth(n) 

nodetype  n; 

GIGelNodeWidth  returns  the  width  of  the  node  n.  This  is  the  value  of  the  node_width  attribute, 
which  is  in  ADAS  grid  coordinates. 

OINodeDiinensions(n,  xsz,  ysz) 
nodetype  n; 
double  *xsz,  ’"ysz; 

GINodeDimensions  sets  the  doubles  pointed  to  by  xsz  and  ysz  to  the  actual  dimensions  of  node  n. 
These  dimensions  are  in  ADAS  grid  coordinates,  but  may  differ  from  the  values  returned  by  GLXo- 
deHeight  and  GINodeWidth  if  n  is  represented  by  an  icon. 

ICONS 

ADAS  graph  elements  may  be  represented  by  icons  which  are  stored  in  files.  If  a  graph  element's 
icon_file_name  attribute  is  not  empty,  the  icon  in  the  named  file  is  used  to  represent  that  ele¬ 
ment.  A  list  of  active  icons  is  maintained  in  the  graphics  interfaccm.  so  an  icon  file  is  only  rend 
once  during  a  session. 
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GIReadlconF  ile(filename) 

char  *filename; 

GIReadIconFile  reads  the  icon  description  tile  filename,  and  puts  rhe  icon  into  the  -ist  oi  active 
icons. 

icon  *GIGetIcon(filename) 
char  *filename; 

GIGetIcon  returns  a  pointer  to  the  entry  in  the  list  of  active  icons  occupied  hy  the  icon  storeti  in 
file  filename.  It  returns  NULL  if  the  icon  is  not  active. 

MISCELLANEOUS  GRAPHICS  ROUTINES 

GIRefresh() 

GIRefresh  refreshes  the  graphics  display. 

boolean  GITooSmall() 

GITooSmall  returns  TRUE  if  the  graph  scale  is  so  small  that  node  labels  and  ports  should  not  be 
drawn. 

char  “GIInquireDisplayDeviceO 

GIInquireDisplayDevice  returns  the  name  of  the  graphics  display  being  used, 
char  ‘‘GIGetDisplayTypeO 

GIGelDisplayType  returns  the  name  of  the  type  of  graphics  display  being  used. 

GIDrawGridO 

GlDrawGrid  draws  tlie  ADAS  graph  grid. 

boolean  GIPortsVisible() 

GIPortsVisible  returns  TRUE  if  the  graph  scale  is  such  that  node  ports  should  be  drawn.  Node 
ports  are  not  drawn  if  they  would  be  so  small  as  to  be  useless. 
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PART  VT 


ADAS  Common  Library  Routines 


INTRODUCTION 

The  ^\DAS  common  library  (libcommonl  conoains  routines  that  are  used  by  more  than  one  ADAS 
program,  but  do  not  belong  in  the  Command  Interpreter.  Data  Base  Routines,  Graphics  Interface, 
Graphics  Package,  or  Editor. 

SHARED  COMMANDS 

These  routines  are  related  to  .ADAS  top-level  commands  that  are  identical  in  EDIGRAF  and  GIP- 
SIM. 

HardcopyO 

Hardcopy  is  the  top-level  routine  for  the  hardcopy  command.  It  prints  a  copy  of  the  current 
graph  on  a  hardcopy  device.  The  user  chooses  from  a  menu  of  available  hardcopy  devices. 

HelpO 

Help  is  the  top-level  routine  for  the  help  command  which  provides  help  on  various  .ADAS  topics. 
The  user  selects  the  tool  and  suiiject  for  which  he  needs  help,  and  the  contents  of  a  help  file  in 
.ADAS  help  directory  are  displayed  on  the  terminal  screen. 

GetHelpTopics(menu,  helpdir) 
menutype  *menu; 
char  *helpdir; 

GetHelpTopics  adds  the  names  of  the  help  files  in  the  help  directory  helpdir  to  the  menu  menu. 

catfile(rile) 
char  *file; 

eatfile  prints  the  contents  of  the  file  .specified  by  pathname  file  to  standard  output.  It  returns  0  if 
the  file  was  successfully  printed  and  I  if  the  file  couldn’t  be  opened, 

Macro() 

Macro  is  the  top-level  routine  for  the  macro  command.  It  provides  for  the  addition,  deletion,  and 
listing  of  macro  commands.  Macro  returns  0  on  a  normal  completion  and  -1  if  an  error  occurred. 

Reload() 

Reload  is  the  top-level  routine  for  the  reload  command.  It  reloads  the  current  graph  from  the 
corresponding  disk  file  after  the  user  verifies  his  intent  to  reload,  .Any  changes  made  since  the 
graph  was  last  saved  to  the  disk  file  are  lost. 

Script() 

Script  is  the  top-level  routine  for  the  script  command.  It  prompts  the  user  for  a  script  file  name 
and  e.xecutes  the  script  file. 
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Stats() 


irats  is  i  he  roD-ievei  routine  for  the  stats  ■•ommand.  ft  provides  statistics  on  graph  elements  of 
rhe  user  s  ••hoioe.  Tlie  user  rnooses  ilie  'ype  of  stats  he  wants  from  a  menu,  "Node"  or  "arc" 
stats  give  the  '’aiues  of  ail  the  attributes  for  a  node  or  arc.  "Latency"  or  "utilization"  redraws  all 
the  nodes  in  a  iie.ated  object  scale  representing  their  relative  latencies  or  utilizations.  A  key  for 
the  color  scaie  is  uisinaved  on  the  screen. 


DrawStatsKeydabell,  label2) 
char  "labeil.  ‘Iabel2; 

DrawStatfiKey  draws  the  color  .scale  kev  for  the  slats  command,  labeling  the  key  with  labell  and 
labels  (minimum  and  maximum  stats  values!. 

node_stats^n) 
nodetype  n; 

nodejitals  print.s  the  attribute  values  for  node  n. 

bus_stats(b) 

bustype  b; 

bu.<i_itats  prints  the  attribute  values  for  bus  b. 

partition_stats(p) 

partitiontype  p: 

partition_stats  print.s  i  he  attribute  values  for  partition  p. 

arc_stats(a) 
arctype  a; 

arc_stats  prints  the  attribute  values  for  arc  «. 

SetQSBounds(labell,  label2) 
char  *labell; 
char  *label2; 

SetQSBounds  prompts  the  user  for  the  lower  and  upper  bounds  for  the  stats  queue  command. 
The  strings  pointed  to  by  labell  and  labels  are  set  to  contain  the  string  representations  of  the 
lower  and  upper  bounds,  respectively.  SetQSBounds  calls  GlSetQueueLB  and  GISetQueueUB  to  set 
the  queue  bounds  for  the  drawing  routines. 

GetQSBounds(Iabell.  Iabei2) 
char  *labell; 
char  *label2; 

GetQSBounds  copies  the  current  queue  size  stats  labels  into  labell  and  labels. 

Window() 

Window  i.s  the  top-level  routine  for  the  window  command.  The  window  command  allows  the  user 
to  zoom  in  or  out  on  a  particular  point  in  the  graph  by  specifying  a  scaling  factor  and  the  point  he 
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wishes  to  zoom  in  on. 


DoWindow(x,  y,  wsize] 

int  X,  y; 
float  wsize; 

DoWindow  centers  the  graph  at  location  (j;.  y)  with  window  oize  wsize,.  \Vi:h  larger  v:ii;ies  li 
wsize,  the  portion  of  the  graph  that  will  be  visible  is  grearer.  and  consequent iy  rtie  grapii  element.^ 
appear  smaller.  If  wsize  is  too  large  the  window  size  used  is  GR.\PHN'IAX. 

LIST  MANAGEMENT 

These  routines  are  used  to  manipulate  alphabetical  lists  of  strings. 

SetFirstNodeAlphabetic() 

SetFirstNodeAlphabetic  creates  an  alphabetical  list  of  the  nodes  in  the  current  data  base  an(i  -ets 
a  pointer  to  the  first  node  in  the  list. 

GetNextNodeAlphabetic(np) 
struct  node  **np; 

GetNextNode Alphabetic  sets  the  pointer  pointed  to  by  np  to  point  to  the  current  node  in  the 
alphabetical  list  of  nodes  and  updates  the  list  pointer  so  that  the  next  node  becomes  the  current 
one. 

boolean  MoreNodesAIphabetic() 

MoreNodesAlphabetic  returns  TRUE  if  there  are  nones  remaining  in  the  alphabetical  list  of  nodes 
and  FALSE  if  there  are  none. 

AIphaNodeAdd(n) 

nodetype  n; 

AlphaNodeAdd  inserts  node  n  into  the  alphabetized  list  of  nodes. 

Alphalnsert(list,  s) 
namelink  **list; 
char  *s; 

Alphalnserl  inserts  the  string  s  into  the  alphabetized  list  of  strings  where  the  head  pointer  is 
pointed  to  by  list. 

int  CompStrings(sl,  s2) 
char  *sl; 
char  *s2; 

CompStrings  compares  si  and  s2  alphabetically  or  numerically  by  trailing  digits  if  the  strings  have 
identical  alphabetic  prefixes.  For  instance,  "al"  would  come  before  "bl  "  but  "b2"  would  come 
before  "bl2."  It  returns  -1  if  si  comes  before  sS,  0  if  si  is  identical  to  .sd,  or  I  if  si  comes  after  .sd. 

FreeList(list) 
namelink  **list: 
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FreeLisT  frees  the  memory  oecupied  bv  the  list  of  strings  -.viiose  ^lead  pointer  is  pointed  to  ov  tin/ 
and  sets  the  head  pointer  to  NLfLL. 

DYNAMIC  MEMORY  MANAGEMENT 

char  '‘‘myallocfnelem,  elsize) 
int  nelem: 
unsigned  elsize; 

myalloc  calls  calloc  to  allocate  memory  for  neie.m  elements,  eacn  of  size  ^isize.  It  .  hecks  to  make 
sure  the  memory  was  actually  allocated  and  returns  a  pointer  to  the  newly  allocated  memorv. 

myfree(x) 
char  *x; 

myfree  frees  the  dynamically-allocated  storage  pointed  to  by  x. 

SIGNAL  HANDLING  AND  TERMINAL  MODES 
SigSetupO 

SigSetnp  sets  up  the  signal  handling  routines  for  the  UN^  signals.  SIGPIPE  .ind  SIGCHLD  are 
ignored.  SIGINT  and  SIGTERM  cause  Trap^'ujnal  to  be  tailed,  and  SIGHIP  :s  handled  by  the 
client-supplied  routine  adasjibort.  SIGTSTP  is  handled  in  its  default  manner.  The  remaining 
signals  are  ignored  by  the  default  action  if  they  should  be.  The  rest  are  handled  by  Cleanup. 

IgnoreSignals() 

[gnoreStgnals  causes  SIGINT  and  SIGTERM  to  be  ignored.  This  .s  used  before  processing  signals 
so  new  signals  coming  in  don’t  mess  things  up. 

TrapSignalO 

TrapSignal  asks  the  user  if  he  really  wants  to  abort  the  program.  If  so.  the  client-supplied  routine 
adasjabort  is  called.  Otherwise,  the  program  continues.  Signals  are  ignored  while  TrapSignal  is 
executing. 

Cleanup(sig) 

int  sig; 

Cleanup  closes  the  graphics  display,  resets  the  signal  sig  to  its  default  behavior,  and  resends  sig  to 
itself. 

Star  tCBreak() 

SlartCBreak  puts  the  terminal  into  cbreak  mode  where  keystrokes  can  be  detected  before  a  car¬ 
riage  return  is  entered. 

StopCBreak() 

SlopCDreak  takes  the  terminal  out  of  cbreak  mode  so  that  a  carriage  return  must  lie  entered 
before  keystrokes  can  be  detected. 
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CONVERSION  ROUTINES 


These  routines  pen’orm  conversions  amoni;  different  data  types. 

atoc(s,  xp,  yp7  - 
char  *.s: 

'.nt  '‘xp,  *yp; 

■itoc  converts  the  string  representation,  t.  of  i  coordinate  into  the  integer  coordinates.  The 
integers  pointed  to  by  xv  and  vp  are  set  ro  the  x  and  y  coordinates,  respectively.  The  string  is  of 
the  form  “x.y".  If  string  has  a  baa  format,  the  location  returned  is  (-1.-1). 

char  •ctoa(x,  y) 

nt  X.  y; 

rAoa  returns  a  pointer  to  a  static  ouffer  containing  the  string  representation  of  the  coordinate  (j:. 
y).  The  buffer  is  overwritten  on  subseouent  calls. 

char  *itoa(n) 

;nt  n: 

itoa  returns  a  pointer  to  a  static  buffer  containing  the  .ascii  representation  of  the  integer  n.  The 
integer  must  have  fewer  than  Jo  decimal  iigit.s. 

CREATING  MENUS 

These  routines  are  used  to  create  .ADAS  menus  to  be  used  with  the  command  interpreter. 

boolean  MakeNodeMenufgd.  menu,  type,  port_status) 

int  gd; 

menutype  **menu: 

int  type: 

int  port_siatus: 

\iakei\odeMenu  creates  a  menu  of  nodes  in  the  graph  specified  by  graph  descriptor  gd  and  sets  the 
pointer,  pointed  to  by  menu,  to  point  to  the  new  menu.  The  values  of  type  and  port_status  deter¬ 
mine  which  nodes  are  added.  The  value  of  port_.$tatns  is  0  if  only  nodes  with  unoccupied  ports  are 
to  be  included.  I  for  only  nodes  with  occupied  ports.  J  for  all  nodes,  and  3  for  all  nodes  with  occu¬ 
pied  or  unoccupied  ports  of  the  type(sl  indicated  by  type.  If  portjilatus  is  not  2.  type  is  inter¬ 
preted  as  a  bit  vector  indicating  which  types  of  ports  should  be  considered.  The  least  significant 
bit  is  for  inports,  the  next  for  outports.  .and  the  third  for  b^sorts.  MakeNodeMenu  returns  TRUE 
if  the  menu  it  creates  is  empty,  and  F.ALSE  otherwise.  It  .assumes  that  gd  is  a  valid  graph  descrip¬ 
tor  and  that  type  and  port_i!tatu.%  are  valid. 

MakeArcMenu(gd,  menu,  tmpflag) 

int  gd; 

menutype  “menu; 
int  tmpflag; 

MakeAreMenu  creates  a  menu  of  arcs  in  the  graph  specified  by  graph  descriptor  gd.  .Also.  Mak- 
eArcXfenu  sets  the  pointer,  pointed  to  by  menu,  to  point  to  the  new  menu.  If  tmpflag  is  nonzero, 
the  menu  is  one  of  arc  templates  and  will  contain  the  arc  template  names  for  the  graph;  otherwise, 
it  is  an  arcs  menu  containing  tlie  names  of  the  source  nodes  found  in  the  graph’s  arcs. 
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X'lakeArcAIenn  returns  TRL^  if  the  menu  is  emptv  xnd  FALSE  otherwise.  It  assumes  gd  is  a  valid 
^rapii  descriptor. 

MakeBusMenui  gd.  menu) 

int  gd: 

Tienutype  ‘‘*!nenu; 

MakeBusAienn  creates  a  menu  of  buses  in  the  graph  specified  by  graph  descriptor  gd  and  sets  the 
pointer,  pointed  ro  by  me.nu.  ro  point  to  the  new  menu. 

MakeNodeAndBusMenulgd,  menu,  type,  port_3tatus) 

int  gd: 

menutype  **menu: 

:nt  type: 

int  port_itatus: 

AlakuNodcAndBu.aAltnn  creates  a  menu  .if  nodes  and  buses  in  the  graph  specified  by  graph 
descriptor  gd  and  sets  the  pointer  pointea  to  by  menu  to  point  to  the  new  menu.  The  type  and 
portjitatus  parameters  are  ii.sed  as  liescribed  in  A!ake\'odeAItnu  for  selecting  nodes  to  be  included. 
.Also,  if  por{_.if(ifu.5  IS  1.  only  buses  having  .at  least  one  arc  attached  to  them  are  included. 

Make JunctionMenui  menu,  b.  occ  ) 
menutype  **menu: 
bustype  b: 
int  occ: 

AlakeJunctionAlenn  creates  a  menu  of  junctions  on  bus  b  and  sets  the  pointer,  pointed  to  by  menu, 
to  point  to  the  new  menu,  [f  arc  is  nonzero,  only  junctions  with  at  least  one  arc  attached  are 
included  in  the  menu. 

MakePartitionMenu(gd,  menu) 

int  gd: 

menutype  ‘*menu: 

MakePartitionAlenu  creates  a  menu  of  partitions  in  the  graph  specified  by  graph  descriptor  gd  and 
sets  the  pointer,  pointed  to  by  menu,  to  point  to  the  new  menu. 

boolean  MakePortMenufmenu,  n,  ports,  occ) 

menutype  **menu: 

nodetype  n; 

int  ports; 

int  occ: 

AfakePortAfenn  creates  a  menu  of  ports  of  node  n  and  sets  the  pointer,  pointed  to  by  menu,  to 
point  to  the  new  menu.  If  occ  is  0.  only  unoccupied  ports  are  included.  If  it  is  1.  only  occupied 
ones  are  included:  if  it  is  2.  all  ports  are  included.  If  occ  is  not  2.  ports  is  interpreted  as  a  bit  vec¬ 
tor  with  bits  set  for  rhe  types  of  ports  to  be  included.  The  least  significant  bit  is  set  for  inports, 
the  next  for  outport.s.  and  the  third  for  biports.  AfakePortAfenn  returns  TRLTj  if  the  menu  is 
empty  and  F.ALSE  otherwise. 

MakeAttMenu(menu,  type,  statflag,  editflag) 
menutype  **menu: 
int  type: 
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boolean  statflag; 
boolean  editflag; 

MakeAttMenu  makes  an  alphabetical  menu  of  attributes  for  rhe  graph  .'!em>"nr  T  /pt* 

NODE,  BUS,  ARC.  PARTITION,  IN.  OUT.  or  BI)  and  sets  riie  pointer.  :  ouued  o  niKnu.  o 
the  new  menu.  If  statflag  is  TRLTl  the  menu  is  for  attribute  statues,  a.in  ertain  arriiDutes  ;re 
not  included.  If  editflag  is  TRUE  only  the  editable  attributes  appear  in  ihe  menu.  Otlier'.vise.  all 
attributes  appear  in  the  menu. 

boolean  CMMakeMenus(menu,  done  flag,  graph  flag,  node  flag,  part  flag) 

menutype  **menu; 

boolean  done_flag; 

boolean  graph_flag; 

boolean  node_flag; 

boolean  part_flag; 

CMMakeMenus  creates  a  menu  pointed  to  by  the  pointer  pointed  to  by  menu.  If  ionejlag  is 
TRUE,  “%done"  will  be  the  first  item  in  the  menu.  If  graph _flag  is  TRUE  ''graph"  ,s  .added.  If 
node _Jlag  is  TRUE  the  names  of  all  nodes  in  the  current  graph  are  added  to  the  menu.  If  pnrl_flag 
is  TRLIE,  the  names  of  all  partitions  in  the  current  graph  are  added  to  the  menu. 

DRAWING  GRAPH  ELEMENTS 

These  routines  are  related  to  the  display  of  ADAS  graphs  on  a  graphics  device.  They  call  '-outines 
in  the  ADAS  Graphics  Interface  (libgraphics). 

DrawNodeAndArcs(n,  erase) 
nodetype  n; 
int  erase; 

DrawNodeAndArcs  displays  the  node  n  and  all  the  arcs  attached  to  its  ports.  If  erase  is  nonzero 
the  node  and  arcs  are  erased  instead  of  drawn. 

DrawBusAndArcs(b,  erase) 
bustype  b; 
int  erase; 

DrawBusAndArcs  displays  the  bus  6  and  all  the  arcs  attached  to  its  junctions.  If  erase  is  nonzero 
the  bus  and  arcs  are  erased  instead  of  drawn. 

Draw  JunctionAndArcs(b,  j,  erase) 

bustype  b; 
int  j; 
int  erase; 

DrawJunctionAndArcs  displays  junction  j  of  bus  6  and  all  the  arcs  attached  to  it.  If  erase  is 
nonzero  the  junction  and  arcs  are  erased  instead  of  drawn. 

CMRcdrawScreen() 

CMRedrawScreeri  redraws  the  graphics  image. 

CenterGraph() 
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boolean  statflag; 
boolean  editflag; 

MakeAttMemi  makes  an  alphabetical  menu  of  attributes  for  rhe  graph  t-iemear  r’/pr  lOFi.VPH. 
NODE,  BUS,  ARC,  PARTITION,  IN,  OUT,  or  BI)  and  sets  me  pointer,  [  oinrec,  'o  ov  nttnu.  o 
the  new  menu.  If  statflag  is  TRLTi  the  menu  is  for  attribute  statues,  arui  err.nin  urniDutes  re 
not  included.  If  editflag  is  TRUE  only  the  editable  attributes  appear  in  'he  ;ne!ui.  Otlierwise.  all 
attributes  appear  in  the  menu, 

boolean  CMMakeMenus(menu,  done  flag,  graph  flag,  node  flag,  part  llag) 

menutype  **menu; 

boolean  done_flag; 

boolean  graph_flag; 

boolean  node_flag; 

boolean  part_flag; 

CMMakeMenus  creates  a  menu  pointed  to  by  the  pointer  pointed  to  by  mew.  [f  done_Jlag  is 
TRUE,  "%done"  will  be  the  first  item  in  the  menu.  If  graph_ftag  is  TRl.E  "graoh"  Is  added.  If 
node _Jlag  is  TRUE  the  names  of  all  nodes  in  the  current  graph  are  added  m  the  menu.  If  part_flag 
is  TRUE,  the  names  of  all  partitions  in  the  current  graph  are  added  to  ttie  menu. 

DRAWING  GRAPH  ELEMENTS 

These  routines  are  related  to  the  display  of  ADAS  graphs  on  a  graphics  device.  Tliey  call  routines 
in  the  ADAS  Graphics  Interface  (libgraphics). 

DrawNodeAndArcs(n,  erase) 
nodetype  n; 
int  erase; 

DrawNodeAndArcs  displays  the  node  n  and  all  the  arcs  attached  to  its  ports.  If  erase  is  nonzero 
the  node  and  arcs  are  erased  instead  of  drawn. 

DrawBusAndArcs(b,  erase) 
bustype  b; 
int  erase; 

DrawBusAndArcs  displays  the  bus  b  and  all  the  arcs  attached  to  its  junctions.  If  erase,  is  nonzero 
the  bus  and  arcs  are  erased  instead  of  drawn. 

DrawJunctionAndArcs(b,  j,  erase) 

bustype  b; 
int  j; 
int  erase; 

DrawJunclionAndArcs  displays  junction  j  of  bus  b  and  all  the  arcs  attached  to  it.  If  erase  is 
nonzero  the  junction  and  arcs  are  erased  instead  of  drawn. 

CMRedrawScreen() 

CMRedrawScreen  redraws  the  graphics  im.ago. 

Center  Graph() 
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inr  type; 


HasOpenPorts  returns  TRUE  if  am'  ports  of  rvpe  fi/pe  on  node  node  are  not  occupied.  F.AJLSE  oth¬ 
erwise.  Valid  values  for  type,  .are  iN.  OUT.  and  Bl. 

boolean  HasUsedPortstnode.  type) 
nodetype  node; 
int  type: 

HasUsedPorta  returns  TRLfE  if  inv  ports  of  type  'i/pe  on  node  node  are  occupied.  FALSE  other¬ 
wise.  Valid  values  for  type  are  IN.  OUT.  and  Bl. 

boolean  HasArcs(nanie) 

char  "name; 

HaaArcs  returns  TRUE  if  node  nmne  has  any  outoiii  arcs,  otherwise  FALSE. 

SetArcJointsfjoint,  tmparc) 
char  **joint; 
arctype  tmparc: 

SetArcJointa  prompts  the  user  to  enter  joints  for  the  arc  tmparc  until  the  user  enters  “Fodone". 
The  joint  values  are  .stored  in  Jotnt. 

SETTING  AND  RETRIEVING  NAMES 

SetGraphName(s) 
char  *s; 

SetGraphName  sets  the  .graph  name  to  -a.  The  graph  type  (hardware  or  software)  is  determined  by 
the  extension  on  .5.  The  default  graph  type  (if  no  extension)  is  software.  If  the  graph  name  doesn't 
have  an  extension  (either  ".swg"  or  ".hwg"),  then  the  current  extension  is  tacked  on.  The  default 
extension  is  SOFTEXT. 

char  *GetGraphName() 

GetGraphName  returns  a  pointer  to  a  static  buffer  containing  the  name  of  the  current  graph 
which  was  set  by  SetGraphName.  The  .static  iiuffer  is  overwritten  on  subserjiieiit  calls. 

SetPgmName(s) 
char  *s; 

SetPgmName  sets  the  program  name  to  -s.  If  the  program  name  has  a  path.  e.g..  "  usr  Too  pgm," 
all  but  the  last  part  is  stripped  off. 

char  *GetPgmNanne() 

GetPgmNarne  returns  a  pointer  to  a  static  buffer  containing  the  name  of  the  program  which  was 
set  by  SetPgmName.  The  static  buffer  is  overwritten  on  subsequent  calls. 

SetCDBName(name,  level) 

char  *name; 
int  level: 
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SetCDName-  sets  r.iie  data  base  name  I'or  the  ^raph  or  subgraph  level  level  in  the  graph  hierarchy 
:o  name.  It  assumes  level  •  :  =  V’tAXDEPTH  and  name  Is  VIAXPATH  or  fewer  characters  in 
length. 

char  *GecCDBName(levei) 

int  level; 

GetGDBName  returns  a  pointer  to  a  static  buffer  containing  the  name  of  the  graph  at  level  level  in 
the  graph  hierarctiy.  The  static  buffer  is  overwritten  on  subsequent  calls. 

char  GetCurrDBDir() 

GetCiirrDBDir  returns  the  name  of  the  directory  in  which  the  current  data  base  file  resides.  The 
first  time  It  is  cailed.  it  stores  the  name  m  a  static  buffer:  then  it  returns  a  pointer  to  that  buffer 
on  that  call  and  subsequent  ones. 

char  *  GetGraphExt() 

GelGraphExt  returns  a  pointer  to  a  static  buffer  containing  the  graph  name  extension  (".swg"  or 
"  .hwg"  )  of  the  current  data  base. 

char  *  MakeSubgrafName(node) 
nodetype  node; 

MakeSubgrafNarne  builds  a  subgraf  name  based  on  the  value  of  the  subgraf_file_name  attribute 
of  node  node.  It  returns  a  pointer  to  the  dynamically  allocated  string. 

char  *  PathFromRoot(node) 

nodetype  node: 

PathFromRoot  creates  the  full  path  name  of  node  from  the  top-level  graph  in  the  graph  hierarchy 
and  returns  a  pointer  to  the  dynamically  allocated  string  containing  the  path  name.  The  full  path 
name  consists  of  the  names  of  node  and  all  its  ancestor  nodes,  starting  with  the  node  in  the  top- 
level  graph,  separated  by  colons 

char  *GetCDBTemplateName(level) 
int  level; 

GelCDBTemplateNanie  returns  a  pointer  to  a  static  buffer  containing  the  name  of  the  template 
data  base  for  level  level  in  the  graph  hierarchy. 

boolean  CMNodeName(s) 
char  *s; 

GMNodeName  returns  TRUE  if  .?  is  the  name  of  a  node  in  the  current  data  base,  F.-VLSE  other¬ 
wise. 

MISCELLANEOUS  COMMON  LIBRARY  ROUTINES 

Tr  averse  AndExpand(level) 

int  level; 

Traver-'ieAnriErpnnd  recursively  traverse.s  the  graph  hierarchy,  e.xpanding  nodes  into  their 
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subgraphs,  then  traversing  the  subgraphs.  The  value  of  level  gives  rhe  ievei  in  rhe  nierarchv  -har 
is  currently  being  traversed.  Its  value  should  be  zero  for  the  initial  l  ail  to  "rnvernK.-iiiaEx-nava. 

Refresh  Window() 

RefreshWindow  redraws  the  entire  graphics  display.  It  is  cailed  from  rhe  graphics  driver  'or  Mie  X 
window  system  to  redraw  the  graphics  window  when  it  is  exposed. 

char  *GetCurrDate() 

GetCurrDate  returns  a  pointer  to  a  static  buffer  containing  the  current  rime  .md  date  in  an 
operating  system-dependent  format.  The  static  buffer  is  overwritten  on  siibseaiient  cails. 

boolean  IsPositive(val) 
int  val; 

IsPositive  returns  TRUE  if  val  is  greater  than  or  equal  to  zero.  F.'J.iSE  otherwi.se, 

boolean  IsValidUB(val) 
int  val; 

IsValidUB  returns  TRUE  if  vat  qualifies  as  a  valid  upper  bound  by  being  greater  tiuin  or  equal  to 
the  current  lower  bound.  It  returns  F.‘\LSE  otherwise. 

get_env(log_name) 
char  *log_name; 

getjenv  returns  a  pointer  to  a  static  buffer  containing  the  value  of  the  V'MS  logical  name 
log_name. 

ErrHandIer(type,  number,  level,  msgf,  ml,  m2,  m3,  m4,  m5) 

char  *type; 

int  number; 

char  level; 

char  *msgf; 

char  *ml; 

char  *m2; 

char  *m3; 

char  *m4; 

char  *m5; 

ErrHandter  prints  an  error  message  in  standard  ^\DAS  format.  The  .string  ttjpe  i.s  appended  to  the 
one-letter  program  code  (usually  the  first  letter  of  the  program  name)  to  form  the  .alphabetic  error 
code.  This  code,  when  combined  with  the  error  number  number,  identifies  the  error.  The  string 
msgf  'is  used  as  the  format  specification  for  the  message  to  be  printed,  and  the  strings  ml  through 
mS  are  put  into  that  format  using  sprint/.  Valid  values  for  the  error  severity  level,  level,  are  "W" 
(WARNING),  "E"  (ERROR),  "D"  (DISASTER),  and  ”A“  (.ABORT).  ErrHandler  assumes  the 
existence  of  a  client-supplied  routine  named  adas_abort  that  terminates  the  program  gracefully. 
This  routine  is  called  if  the  severity  level  is  DISASTER  or  .ABORT. 

PrintHeader() 

Prinllleader  prints  a  standard  .AD.\.S  program  header.  This  header  includes  program  name. 
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version  number,  and  a  copyright  notice.  The  program  name  to  be  used  is  set  witn  .'KiPjmName. 


int  GetMajorVer() 

G'ebV/ayorTer  returns  the  current  .ADAS  major  version  number.  ‘'‘J"  ;or  ersion  'l.Z. 

int  GetMinorVer() 

GetMinorVer  Ttx,Mvns,  the  current  .ADAS  minor  version  number,  i.e.  for  V'ersion 

strlcpy(sl,  s2,  n) 
char  *sl, 
char  *s2; 
int  n; 

atrlcpy  copies  up  to  n  characters  from  to  al.  (t  assumes  al  is  large  enough  to  hold  n  characters. 

boolean  true() 

true  returns  the  boolean  value  TRUE.  This  is  useful  when  a  pointer  to  a  function  that  will  always 
return  TRUTl  is  needed. 

boolean  IsRelPath(path) 
char  *path; 

IsRelPath  returns  TRUE  if  the  path  is  a  'V'\IS  relative  path  name,  and  F.ALSE  otherwise.  On 
UNDC  this  is  accomplished  with  a  macro. 

boolean  PortMismatch(node,  subgrname) 
nodetype  node; 
char  *subgrname; 

PortMismatch  checks  that  the  graph  inports  and  graph  outports  of  the  subgraph  named 
subgrname  match  in  number,  the  inports  and  outports  of  its  parent  node.  node.  It  also  checks  the 
graphport  numbers  of  the  graphports  in  the  subgraph.  If  there  is  an  error.  PortMismatch  prints 
an  error  message  and  returns  TRUE.  Otherwise  it  returns  F.ULSE. 

Tmpllnit(tgd,  create) 
int  *tgd; 
boolean  create; 

Tmpllnit  initializes  the  template  data  base  for  the  current  graph.  If  create  is  TRUE,  a  new  tem¬ 
plate  data  base  is  created.  The  integer  pointed  to  by  tyd  is  set  to  the  template  graph  descriptor. 

boolean  file_exists(file) 
char  *file; 

filejexists  returns  TRUE  if  the  file  named  file  exists;  otherwise.  F'ALSE.  It  uses  the  access  system 
call. 

boolean  node_exists(name) 
char  *name; 
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nodej-.xints  returns  TRLIE  if  a  node  -vith  name  name  exists  in  the  ourrent  data  base,  otherwise 
F.\LSE. 

3etPgmCode() 

SetPjmCode  sets  the  program  error  eode.  based  on  the  program  name  returned  by  GetPgmName. 
The  program  error  eode  is  used  in  .\DAS  error  messages.  SetPgmName  should  always  be  called 
before  SetPgmCode.. 

StatSym(st) 

mt  St; 

StatSyrn  returns  the  value  of  the  character  associated  with  modification  status  st  for  the  Slats 
command. 

ValidLocation(loc) 
char  *loc 

ValidLocation  determines  whether  loc  is  a  valid  port  location  specification.  It  returns  1  if  loc  is 
valid  and  0  otherwise. 

boolean  CMNodeOrBusName(name) 
char  *name; 

CMNodeOrBusName  returns  TRUE  if  name  is  the  name  of  a  node  or  bus  in  the  current  graph,  and 
FALSE  otherwise. 

CMNodeOrient(n) 
nodetype  n; 

CMNodeOrient  returns  the  node  orientation  of  node  n.  either  LiP.  DOWN,  LFT,  or  RIGHT. 

char  *  CMGetPortLoc(node,  port,  ioflag) 
nodetype  node; 
int  port; 
int  ioflag; 

CMGetPortLoc  returns  a  pointer  to  astatic  buffer  containing  the  string  representation  of  the  loca¬ 
tion  of  port  port  of  type  ioflag  on  node  node.  If  there  is  no  location  explicitly  specified  in  the 
port’s  location  attribute,  the  default  location  is  computed  and  converted  to  string  form.  The  loca¬ 
tion  string  consists  of  a  one-letter  direction  code  (’N’,  ’S’,  by  a  slash. 

boolean  CMNodeFromGraph(s) 

char  *s; 

CXlNodeFromGraph  returns  TRUE  if  •?  is  the  name  of  a  node  in  the  current  graph,  and  F.'VLSE 
otherwise. 

CMRedrawContextO 

CMRedratuContezt  redraws  the  .AD.^S  context  window. 

TheEnd(status) 
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inc  staous: 


ThtEnd  terminaies  .\DA.S  ^raphie.-s  and  'xks  the  program. 


int  CMGraphLocInWmdow(c) 

'■oordtype  c: 

CMGraphLocln  Window  returns  a  nonzero  value  if  coorinace  c  is  in  the  current  graph  window,  zero 
otherwise. 

int  IsUnoccupied(loc) 

coordtype  loc;  returns  a  nonzero  value  if  the  location  loc  is  a  valid  graph  location  and  is  not 
already  occupied  by  a  node  or  junction,  zero  otherwise. 

boolean  CMCaselessCmp(si.  s2) 
char  *.sl: 
char  *s2; 

CMCaselessCmp  does  a  caseless  string  comparison  of  .si  and  .si?.  It  returns  a  negative  value  if  si 
precedes  -si?  aiphabeticaily.  zero  if  they  are  the  same,  and  a  positive  value  if  si  follows  sS. 

int  CMIsInBounds(c) 
coordtype  c: 

CMIsInBounds  returns  a  nonzero  value  if  coordinate  c  is  within  the  valid  graph  coordiante  range, 
zero  otherwise. 

TEA  AND  VSCI  STUFF 

boolean  CMBusInArcSubrange(subelement,  ap) 
int  subelement: 
arctype  ap; 

CMBusInArcSnbrtingt  returns  TRLE  if  subelement  is  included  in  the  bus_subrange  of  arc  ap, 
and  F.ALSE  otherwise. 

CMBusN  etlist() 

CMBusNetiist  allows  the  user  to  select  a  bus  from  a  menu,  then  prints  the  netlist  for  that  bus. 

CMCheckArcSubRange(ap) 

arctype  ap: 

CMCherkArcSnbRamje  checks  the  value  of  the  bus_subrange  attribute  for  arc  ap.  It  returns 
NOCRROR  if  the  value  is  valid  and  CANCEL  otherwise. 

CMCheckNodeCount() 

CMCheekNodeCount  ciiecks  whether  the  graph  attribute  graph_node_count  exists.  If  so.  it 
counts  the  number  of  nodes  in  the  current  graph  and  sets  the  graph_node_count  attribute  to 
that  value. 
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CMCheckPartitionCount() 


CMCheckPartitionCount  checks  whether  the  grapn  attribute  graph_partition_:oum;  xi^rf.  if 
so,  it  counts  the  number  of  partitions  in  the  current  graph  and  iers  "he  graph  partition  count 
attribute  to  that  value. 

CMEatBlanks(buffer) 
char  **buffer; 

CMEatBlanks  removes  leading  and  trailing  blanks  from  the  string  pointed  to  oy  hnffe.r. 

CM£ditFile(fiIename,  def  editor) 
char  *filename; 
char  *def_editor; 

CMEditFile  allows  the  user  to  edit  file  filename  using  the  editor  dejjiditor. 

CMFileCheck(filename,  exist,  err_type,  epr_num) 

char  *filename; 

boolean  ‘exist; 

char  ‘err_type; 

int  err_num; 

CMFileCheck  checks  the  existence  of  the  file  filename,  setting  the  boolean  pointed  to  by  eiint  to 
TRUE  if  it  exists  and  FALSE  otherwise.  An  error  message  is  printed  if  m  an  error  occurs  in 
obtaining  the  status  of  the  file,  (2)  the  file  is  a  directory  or  special  file,  or  i:’)  the  user  does  not 
have  read  permission  on  the  file.  The  client  of  CMFileCheck  passes  it  the  error  type.  err_type.  and 
the  error  number,  err_num  for  use  in  the  error  message. 

CMFileCopy(dest,  src,  err_type,  err_num) 

char  *dest; 

char  ‘src; 

char  ‘err_type; 

int  err_num; 

CMFileCopy  copies  the  file  named  src  to  the  file  named  desl.  If  either  file  cannot  be  opened,  an 
error  message  is  printed.  The  errJLype  and  err_num  parameters  are  used  as  in  CMFileCheck. 

CMGetConnType(node) 
nodetype  node; 

CMGelConnType  returns  the  connection  type  of  node  node.  This  is  INTERIOR  if  the  node's 
node_class  is  LEAF  or  INTERNAL,  and  EXTERIOR  otherwise. 

char  •CMGetEditor(spec_editor) 
char  ‘spec_editor; 

CMGelEditor  returns  the  name  of  the  editor  of  the  user’s  preference.  It  first  checks  the  EDITOR 
environment  variable.  If  that  is  not  set,  it  uses  spec_editor.  if  Nl'LL,  it  uses  the  system  default 
editor.  On  VMS  the  default  editor  is  "edit":  on  L'NIX  it  is  "  /usr/ucb/vi" . 

CMGetFileByNodeAtt(att,  ext,  gd,  doexist,  filename) 

int  att; 
char  *ext; 
int  gd: 
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boolean  doexist: 
char  **filename: 

CMGetFihByNodeAtt  displays  a  menu  of  file  names  recnered  from  .Ltr.ributp  itt  in  rhti  nodes  ;n 
the  graph  specified  by  graph  descriptor  gd.  When  the  user  selects  i  name,  riie  extension  -,xt  is 
appended  to  it.  The  existence  of  the  file  with  the  resuiting  name  is  .'necked  according  'o  rhe  vauie 
of  doexist.  If  doexist  is  TRUE  and  the  file  does  not  exist,  and  error  message  ;s  printed.  If  it  is 
FALSE  and  the  file  exists,  the  user  is  asked  whether  he  w.nnts  to  replace  Mie  file,  if  he  does  not. 
CMGetFileByNodeAtt  returns  CANCEL.  The  pointer,  pointed  to  by  fiiename.  is  set  to  point  to  a 
static  buffer  containing  the  selected  filename  with  its  extension. 

int  CMGetLeftSubRange() 

CMGetLeftSnbRange  returns  the  leftmost  element  of  rhe  current  arc  -  uorange. 

CMGetNodeAttMenu(gd,  att,  inenu_ptr) 
int  gd; 
int  att; 

menutype  **menu_ptr; 

CMGetNodeAttMemi  creates  a  menu  of  the  values  of  attribute  alt  for  tlie  nodes  in  the  graph  speci¬ 
fied  by  graph  descriptor  gd.  The  pointer  pointed  to  by  menn_ptr  is  set  to  the  new  menu. 

CMGetNodeByAttVal(gd,  att,  value,  node,  tmpl) 

int  gd; 

int  att; 

char  *value; 

nodetype  ‘node; 

char  ‘tmpl; 

CMGetNodeByAttVal  checks  the  graph  specified  by  graph  descriptor  gd  for  nodes  in  which  the 
value  of  attribute  att  is  value.  It  sets  node  to  point  to  this  node.  If  more  than  one  node  has  a 
matching  attribute,  the  template  name  for  the  nodes  is  copied  into  the  buffer  tmpl.  If  nodes  with 
matching  values  have  different  template  names,  an  inconsistency  warning  message  is  printed. 

CMGetPortClass(node,  port,  ioflag) 
nodetype  node; 
int  port; 
int  ioflag; 

CMGetPortClass  returns  the  port  class  of  port  port,  of  type  ioflag,  on  node  node.  This  is  either 
SCALAR,  CONSTRAINED,  or  UNCONSTRAINED. 

CMGetPortName(node,  port,  dir) 

nodetype  node; 
int  port; 
int  dir; 

CMGetPortName  returns  a  pointer  to  a  static  buffer  containing  the  port  name  of  port  port,  of  type 
dir,  on  node  node.  This  is  of  the  form  "lNPORT_X",  where  X  is  the  port  index,  port. 

CMGetPortRefName(node,  port,  ioflag) 

nodetype  node; 
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inc  port: 

^nt  iot'lag; 

'^MGiitPortRajNnme.  returns  i  uoiiuer  to  a  static  oiiiTer  .-ontaining  a  string  associated  with  port 
port  01  type  ‘'o//aij  on  node  noiie.  if  noiir.  is  a  grapn  oort.  the  string  is  the  node  s  name.  Other¬ 
wise.  the  string  is  the  one  returned  hy  '.'.'/6'rifP?<r/Avj/ne. 

Int  CMGetPo^tS^bnumbe^^subeiemenTl) 
int  subelement; 

CMGetPortSnbnuinbe.r  returns  the  subelement  of  the  array  port  to  which  bus  subeiement  subele- 
ment  is  connected. 

char  '“CMGetPortWidthlnode,  port,  dir) 
nodetype  node; 
int  port; 
int  dir: 

CMGetPortWidth  returns  a  pointer  to  astatic  buffer  containing  the  value  of  the  width  attribute  of 
port  port  of  type  dir  on  node  node..  This  buffer  is  maintained  by  the  .\DAS  data  base  and  will  be 
overwritten  on  the  first  subsequent  ';all  to  DBGetPorlAtt. 

int  CMGetRightSubrange()  returns  the  rightmo.st  element  of  the  current  arc  subrange. 

CMIsBlank(buffer) 
char  ‘buffer; 

CMIsBlank  returns  TRUE  if  all  the  characters  in  the  string  buffer  are  white  space  characters 
(space,  tab.  newline,  form-feed),  and  F.ALSE  otherwise. 

CMIsContigSubrange() 

CMIsConligSubrange  returns  TRUTi  is  the  current  subrange  is  contiguous.  F.-VLSE  otherwise. 

CMMakeFileMenu(directory,  ext,  menu) 
char  ‘directory; 
char  ‘ext; 
menutype  “menu: 

CMMakeFUeMenu  creates  a  menu  of  files  in  directory  direclonj  with  file  extension  ext.  The 
pointer,  pointed  to  by  menu,  is  set  to  point  to  the  new  menu. 

Itok  CMNext_Token(busrange) 

char  busrangeij; 

C\INext_Token  returns  the  next  token  in  busrange. 

CMReplaceFile(rilename,  replace) 

char  ‘filename; 
boolean  ‘replace; 

CMRepIncef'ile  .a.sks  the  user  whether  he  wants  to  replace  file  filename.  The  lioolean  pointed  to  by 
replace  is  set  to  TRUE  if  he  answers  "yes"  and  to  F.\LSE  otherwise. 
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CMSetArcSubRangei  actstring) 

char  ‘ j,t,t.far.ring; 

CMSetArcSubRdn<jt  parse.s  rhe  arc  bus_3ubrange  vaiue  given  in  attsinng  into  its  individual  bits, 
and  puts  the  .aparopriate  bit  '.'alues  into  tlie  global  subrange  .irray  lor  future  reference. 

CMSetFileAtt(  type,  name,  exc,  att..  file_name,  exist) 

int  type: 

char  '‘name: 

char  *axt: 

int  att: 

char  ‘*file_name: 
boolean  '“exist: 

CMSetFileAtt  prompts  the  user  for  a  value  for  att  att  of  graph  element  name  of  type  type.  This 
attribute  should  .-enresent  a  file  name.  If  the  file  whose  name  the  user  enters  already  exists,  the 
boolean,  pointed  to  by  exist,  is  .-;et  to  TRLiE  and  the  user  is  asked  whether  he  wants  to  replace  the 
file.  The  pointer,  pointed  to  by  file_'iam.e.  is  set  to  point  to  a  static  buffer  containing  the  file 
name  entered  by  the  user. 

CMSetNodeByClasslgd.  class,  template,  node) 
int  gd: 
int  class: 

boolean  template: 
nodetype  *node; 

CMSetNodeBijCla.s.s  creates  a  menu  of  nodes  from  the  graph  specified  by  graph  descriptor  gd, 
using  class  as  a  bit  vector  in  which  bits  are  set  for  the  classes  of  nodes  to  be  included.  If  teinplate 
is  TRUE,  the  menu  contains  node  templates  instead  of  nodes.  The  node  pointed  to  by  node  is  set 
to  the  node  selected  from  the  menu. 

CMSysError(err_code,  err_num,  target) 
char  *err_code; 
int  err_num; 
char  ‘target; 

CMSysError  prints  an  .VD.AS  error  message  using  the  err_code  and  err_num  provided.  The  target 
argument  names  the  item  (e.g..  file)  that  was  responsible  for  the  error. 

boolean  CMYes(prompt,  cancel) 
char  ‘prompt; 
boolean  ‘cancel: 

CMYes  presents  the  user  with  a  "yes  no"  menu  and  the  prompt  prompt,  and  gets  his  respon.se. 
The  boolean  pointed  to  by  cancel  is  set  to  TRUE  if  the  user  cancels  and  to  F.\LSE  otherwise. 
CMYes  returns  TRUE  if  the  user  enters  “ye.s"  and  F.-VLSE  otherwise. 
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ADAS  Interrupt  Handling 


All  VMS  exceptions  that  are  not  mentioned  in  the  Interrupt  :-equiremeals  sections  'n' 
particular  TLCSCs  will  be  fielded  and  will  generate  the  same  result: 

a.  a  tool  specific  interrupt  handler  will  be  called. 

b.  all  open  files  will  be  closed. 

c.  the  current  contents  of  the  .ADAS  internal  data  base,  if  present,  -vill  iie  mved 
in  an  .ADAS  data  base  file  with  a  special  suffix,  and 

d.  the  Interrupt  handler  will  let  the  VMS  exception  handling  mechanism  con¬ 
tinue. 

Under  UNIX  the  various  signals  are  handled  as  follows: 

a.  The  hangup  signal,  SIGHUT.  causes  the  tool  specific  interrupt  handler  to  he 
called. 

b.  When  the  interrupt  signal,  SIGINT,  or  the  software  termination  signal. 
SIGTERM,  is  received,  the  user  is  asked  to  confirm  his  intention  to  abort  the 
program.  If  he  assents,  the  tool  specific  interrupt  handler  is  called.  Other¬ 
wise,  the  program  resumes  execution  at  the  point  where  the  signal  was 
received. 

c.  The  signals  generated  upon  writing  to  a  nonexistent  pipe.  SIGPIPE.  and  when 
the  status  of  a  child  process  changes,  SIGCHLD,  are  ignored. 

d.  For  SIGTSTP,  which  is  generated  when  the  user  generates  a  stop  signal  from 
the  keyboard,  the  default  action  is  performed. 

e.  Among  the  remaining  signals,  those  whose  default  action  is  to  he  ignored  are 
ignored.  For  any  others,  the  graphics  device  is  first  closed,  then  the  default 
action  for  that  signal  is  performed. 
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Appendix  E 

BIT  Module  Application  Notes 


8-BIT  EQUAL  COMPARATOR 
.\PP LIGATION  NOTE 


Objective 

The  objeotive  of  rhis  application  note  is  ^’o  describe  the  fiincrionalit.y  of  an  S-!)it 
comparator  module  and  to  show  how  it  is  used  in  a  design  :o  facilitate  .est. 

Block  Diagram 


ain[l]  aiii[8]  bin[l!  bln  [Si 


ain[ij  ain[8]  bin[l]  bin  [8]  not_equal 


Figure  1.  Block  Diagram  of  the  8-bit  Comparator  Module 
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Pin  Description 


Name 

Description 

aini8:.l| 

Operand  A  p.-'railei  data  inputs 

bin[8:l] 

Operand  3  parallel  data  inputs 

not_equal 

If  A  equals  B.  then  this  signal  is  low 

Function  Table 

The  following  table  shows  the  complete  function  of  the  8-bit  parity 
generator/checker. 


Function  Table 


Function 

not_equal 

A  =  B 

L  1 

A  >  B 

H 

A  <  B 

H 

Incorporation  of  the  Equal  Comparator  Modules  into  Design 

A  hardware  design  can  be  partially  tested  by  duplicating  modules  and  comparing 
the  outputs  of  the  two  modules.  If  there  is  a  difference  in  the  output  values,  then  one 
or  both  of  the  modules  is  not  calculating  its  result  properly  or  the  comparator  is  faulty. 
This  is  a  concurrent  form  of  testing  which  allows  the  user  to  see  if  there  is  a  mismatch 
of  data  results  between  two  equivalent  modules.  Figure  2  shows  an  example  use  of  a 
Comparator  module. 
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Figure  2.  Example  Showing  the  Incorporation 
of  a  Comparator  Module  in  a  Design 
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9-BIT  PARITY  GENERATOR/CHECKER 
.APPLICATION  NOTE 

Objective 

The  objective  of  this  application  note  is  to  describe  the  functionality  of  the  Q-bit 
parity  generator/checker  module  and  to  show  how  it  is  used  in  a  design  to  facilitate 
test. 

Block  Diagram 

din[l]  din[2|  din[9| 

«  «  » • 

_ _ _ i _ 

PARITY  GENERATOR/CHECKER 

u  I  I  j 

din[l]  din  [9]  oddsum  evensum 

Figure  1.  Block  Diagram  of  the  9-bit  Parity  Generator/Checker  Module 
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Pin  Description 


Name  Description 


diniQ:lj  Parallel  data  inputs  of  rhe  parity  generator/checker 

oddsum  Hi^h  output  indicates  an  odd  number  of  high  inputs 
Low  output  indicates  an  even  number  of  high  inputs 

evensum  High  output  indicates  an  even  number  of  high  inputs 
Low  output  indicates  an  odd  number  of  high  inputs 


Function  Table 

The  following  table  shows  the  complete  function  of  the  9-bit  parity 
generator/checker. 


Function  Table 


Number  of  Inputs  That  Are  High 

Outputs 

Evensum  Oddsum 

0.2.4.6.8 

1,3.0, 7 ,9 

H  L 

L  H 
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Chaining  to  Accommodate  a  25-bit  Bus 


Figure  1  shows  how  to  itse  h  parity  geaerator/checker  modules  to  accommodate  a 
25-bit  bus. 


evensum 


evensum: 

H  =  even.  L  =  odd 


oddsum; 

L  =  even,  H  =  odd 


evensum 


Figure  2.  Application  Example  Showing  the  Chaining  of  Three  Modules 

to  Accommodate  a  25-bit  Bus 

Incorporation  of  the  Parity  Generator/Checker  Modules  into  Design 

A  hardware  design  can  be  partially  tested  by  using  parity  generators/checkers  on 
sources  and  receivers  of  the  bus  lines.  This  is  a  concurrent  form  of  testing  which 
allows  the  user  to  see  if  there  1*5  a  mismatch  of  data  between  the  source  and  the 
receiver. 
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bus 

- ^ 

- »i 

’  S(M.irce 
Rei'erence - ^ 


parity 


!  Receiver 


Figure  3.  Example  Showing  the  Incorporation  of  Odd 
Parity  Generator/ Checker  Modules  in  a  Design 
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BUILT-IN  LOGIC  BLOCK  OBSERVER  (BILBO) 
APPLICATION  NOTE 


Objective 

The  objective  of  this  application  note  is  to  describe  r.he  functionality  of  a  built-in 
logic  block  observer  (BILBO)  module  and  to  show  how  ;t  is  used  in  a  design  in  order 
to  facilitate  test. 

Block  Diagram 


out(l|  out[2]  out[16]  tout 


Figure  1.  Block  Diagram  of  a  BILBO  Module 
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Pin  Description  (see  also  the  logic  diagram  and  module  functions) 


Name 

Cj,  Co  and  C'n 

enble 

tetri 

tphil /tphi2 
reset 

reset  1 

shiften 

sin 

d[16:l] 

out[l6:l] 

tout 


Description 

Mode  control  In  purs 
Shift  enbie  for  controi  inputs 
Tristate  control  for  ■'tout  "  output 
Two- phase  clock 

Reset  input  of  all  the  flip-flops  excluding  the  one 
corresponding  to  “shiften  "  input 

Reset  input  of  the  flip-flop  •orresponding  to  the  “shiften" 
input 

Shift  enble  for  data  Inputs 
Serial  data  Input 
Parallel  data  inputs 
Parallel  data  outputs 
Serial  test  ilata  output 
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Module  Functions 


G,]  C.ji  C^i  enl)ie  ihiffcl 

0  1  0/1  1  1  Serial  shifting  in  of  data 

through  ‘‘sin” 

1  0  1  0/1  1  Parallel  transfer  of  inputs 

from  '‘dflGilj”  to  "out[l6:i]” 

1  1  0  0/1  1  Test  pattern  generator  mode; 

pseudorandom  outputs  are 
produced  at  "out  [I6;l]” 
outputs 

1  1  1  0/1  1  Parallel  signature  analyzer 

mode;  parallel  data  vectors 
at  “d{l6:l]”  are  compressed 
into  a  final  signature  at 
"out[l6:l]”  outputs 

0/1  0/1  0/1  0/1  0  Shifting  of  data  is  disabled; 

“out[l6:l]”  outputs  retain 
their  previous  clock  cycle 
values 


Enble  =  0  latches  the  control  inputs  "Ci”,  "Co”,  "03’'.  "shiften”.  and  "sin",  and 
prevents  further  alteration  of  the  latched  values;  “tout"  assumes  a  high  impedance 
state  (Z)  when  “tetri"  =  0.  When  “tctrl”  =  1,  “tout"  =  "out[l6]". 
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Incorporation  of  the  BILBO  Modules  into  Design 

A  iiardware  .iesi’^n  wii!  be  partitioned  into  ambiguity  groups  (AG)  of  iiiterron- 
aected  eiiips  prior  to  rhe  incorporation  of  the  BILBO  modules.  The  example  in  Figure 
3  shows  their  incorporation  in  a  design. 


Before  BIT  Aloduie 
Incorporation 


After  BIT  Module 
Incorporation 


Inputs  to  AG-l  Inputs  to  AG-2 


Figure  3.  An  Example  Showing  the  Incorporation  of  the  BILBO  Modules 
in  a  Design 


As  evident  from  the  figure,  all  inputs  to  an  AG  pass  through  a  BILBO  module  and 
the  AG  outputs  are  connected  to  the  “d”  port  of  another  BILBO  module.  Another 
example  illustrating  the  incorporation  of  the  BILBO  modules  is  shown  in  Figure  d. 
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Figure  4.  Another  Example  llhistrar.im^  ‘he  i'n('orpf7i-ation  n'  ‘lie  3IL3C 
Modules  in  a  Design 


A  master  test  control  unit  (TCF")  is  assumed  to  i)e  present  i:i  die  ^v.^rein  in  uruer 

to  perform  the  following  functions: 

1.  Checking  functionality  of  the  BILBO  modules: 

2.  Prov'iding  deterministic  patterns  to  the  AG  under  test,  if  necessary,  'yv  'hifting  in 
data  through  ■'sin”  input  of  the  relevant  BILBO  module(s): 

3.  Collecting  test  responses  (i.e..  final  signatures)  through  ■'lour''  nodes  if  the 
BILBO  modules,  performing  the  necessary  comparison  with  the  expected  'igna- 
tures.  and  evaluating  the  status  of  the  AGs: 

•1.  Providing  all  the  necessary  control  signals  such  as  ’‘Ci".  ■C',  ".  and  ■  eniue" 

for  the  BILBO  modules: 

•5.  Exercising  proper  control  over  the  ACi  clocks  and  the  BILBO  moduie  clocks 
tphil/tphi2. 
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Before  discussing  :i  sr,ep-liy-scep  procedure  for  ''escing  ‘he  AGs.  rhe  following 
Issues  are  to  l)e  considered; 

1.  Incorporation  of  the  3ILBG  moauies  into  a  '-iesign  introduces  additional  latency  of 
one  clock  cycle  between  AGs.  Gse  of  BILBO  modules  is  not  ;'ecoinmended  for 
fault  isolation  testing  when  sucii  a  latency/  is  not  acceptable  during  normal  opera¬ 
tion. 

‘2.  It  may  be  preferable  to  treat  the  control  inputs  of  an  AG  differently  from  its  data 
inputs  and  use  different  BILBO  moauies  in  conjunction  with  'ontroi  .and  lata 
inputs,  as  shown  in  Figure  5. 

Before 

BIT  Insertion 


After 

BIT  Insertion 


Figure  5,  .An  Example  Illustrating  the  Use  of  Different  BILBO  .Modules 
for  Control  and  Data  Inputs  of  an  AG 
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This  feature  facilitates  the  application  of  deterministic  test  patterns  at  the  control 
inputs  of  an  AG  while  allowing  pseudorandom  patterns  to  be  applied  at  its  data 
inputs.  Even  though  the  logic  diagram  shown  for  the  BILBO  module  assumes  a 
word  size  of  16  bits,  in  practice,  modules  with  smaller  word  sizes  (-4  bits.  8  bits, 
etc.)  may  also  be  utilized  in  order  to  reduce  the  unused  pins  of  the  BIT  modules 
and  hence  possibly  save  some  board  space. 

It  is  also  conceivable  to  pass  only  the  data  inputs  of  an  AG  through  a  BILBO 
module  while  allowing  the  control  inputs  to  be  directly  connected,  as  shown  in 
Figure  6. 


Figure  6.  An  Example  in  which  a  BILBO  Module  is  Used  Only 
for  the  Data  Inputs  of  an  AG 


In  such  a  scheme,  it  is  generally  assumed  that  the  .A.Gs  that  generate  the  control 
inputs  are  tested  first,  and  their  outputs  are  set  to  desired  values  during  the  test 
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of  other  AGs.  The  feasibility  of  properly  implementing  this  scheme  depends  on 
sev^eral  factors  such  as  the  design  of  AGs  in  the  system,  required  fault  Isolation 
resolution,  etc'.,  and  this  scheme  is  not  considered  in  the  step-by-step  procedure 
given  subsequently. 

3.  If  the  number  of  inputs  or  outputs  of  an  AG  exceed  the  default  word  size  of  the 
BILBO  module,  multiple  BILBO  modules  need  to  be  used.  The  BILBO  modules 

shown  in  Figure  2  cannot  be  cascaded  to  form  an  equivalent  larger  word-size 

\ 

module.  Hence,  separate  BILBO  modules  per  each  set  of  AG  I/O  need  to  be  used. 
This  is  not  a  limitation  in  general,  since  the  BILBO  module  in  Figure  2  uses  a 
primitive  feedback  polynomial  to  give  a  maximal  repetition  interval  for  the  gen¬ 
erated  test  vectors  [l].  Furthermore,  uncorrelated  test  vectors  can  be  generated 
by  initializing  the  various  BILBOs  in  the  system  with  different  seeds  (initial  test 
patterns).  Also,  the  error  escape  probability,  when  the  BILBO  module  is  used  as  a 
signature  analyzer,  is  acceptably  low  (<  2~'®)  for  a  16-stage  BILBO  module. 

A  Procedure  for  Testing  of  AGs 

Preliminary  Steps 

1.  Reset  all  the  BILBO  modules  in  the  design  by  applying  “reset”  and  “resetl”  sig¬ 
nals. 

2.  Bring  all  the  AGs  into  predetermined  and  well-defined  states  by  means  of  global 
control  signals  such  as  “reset”  and  “preset”,  and  then  disable  the  .\G  clocks  from 
further  altering  their  state. 
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Select  each  31L30  rnohule  by  aieans  oi’  :ts  ■’enbie  "  >i2nal.  shift-in  arei.ieiermine'i 
iata  liternacing  axes  ana  lernsi  :  iiroui^h  ■'siii  '  hipnt  iiiae:-  Mie  •aiurai 

'phil/tphi'J  clocks,  ana  ^■el•iiy  riie  '.Micnut  iaia  at  '■’‘onr  ‘  noiie.  T'ien  .•ecani’i'aur'- 
'he  3ILBO  as  test  pattern  '.^enerntor  iCbi  =  c-iifri  =  i. -■  aia 

verify  the  ontpm  -iata  :it  ''tour  "  ['or  a  predeterminea  number  r,i‘  'docn  ■yeie-r'.  if 
there  3  an  error  in  the  scanneti  ,>nt.  data,  --ither  the  BILBO  moanie  dseif.  ai-  die 
AC  connected  to  its  outputs,  or  both  couid  he  fauity.  The  first  choice  for  tepiace- 
tnent  in  rdiis  case  '.voiiid  iie  i:he  BILBO  raoduie  rather  than  the  aG  since  :  lie  aC 
will  be  checked  in  subsennent  tests. 


4. 


perform  a  parallel  transfer  of  lata  from  ■■df46;[l”  ro  ■‘outlibii!"  in  everv  BILBO 
module,  and  verify  the  stored  data  iiy  leriaily  shifting  it  out  through  ■tour  ’.  In 
this  context,  both  reset  and  preset  capabilities  of  AG.s  may  be  required  so  that 
■■clll6;l]”  nodes  can  assume  both  logic  one  as  well  as  zero  vabms.  If  rhe  sccinned 
out  data  Is  erroneous,  fanit  isolation  can  be  achieved  to  the  combination  of  an 
AG.  a  BILBO  module,  and  the  inherent  inie.^connections  under  the  single  hnuty 
AG  assumption. 


AG  Testing 


5.  Shift  in  a  predetermined  control  data  pattern  into  the  BILBO  module  a-ssociated 
with  the  control  inputs  of  the  AG  under  test;  then,  by  disabling  further  shifting 
!'“shiftl”  =  0).  the  .AG  is  set  up  for  fest  under  a  known  control  mode. 

6.  Configure  the  BILBO  modules  :issociated  with  the  data  inputs  of  the  AG  under 
test  as  test  pattern  generators  and  those  associated  with  the  AG  outputs  as  signa¬ 
ture  analyzers.  It  may  be  required  to  hold  some  or  all  of  the  remaining  AG  out¬ 
puts  at  predetermined  states  during  this  test  so  that  any  faults  internal  to  the 
AGs  not  under  test  do  not  affect  the  signatures  relevant  to  the  AG  under  test. 
Pseudorandom  patterns  generated  by  the  test  pattern  generators  are  automati¬ 
cally  applied  to  the  AG  inputs,  and  the  AG  responses  are  compressed  by  rhe  sig¬ 
nature  analyzers.  During  this  test,  the  .AG  clocks  are  assumed  to  bear  appropriate 
frequency  and  phase  relationships  with  the  test  clocks  tphil/tphi’J. 

.After  a  predetermined  number  of  clock  cycles,  apply  "resetl”  signal  and  disable 
shifting  in  all  the  BILBOs.  Then,  select  each  relevant  BILBO  operating  as  a  sig¬ 
nature  analyzer  and  shift  out  the  stored  signature  through  '‘tonl"  node.  Compare 
this  signature  with  the  expected  one,  obtained  a  priori  from  simulation,  and  deter¬ 
mine  the  status  of  the  .AG. 


Repeat  steps  -b  and  6  for  different  control  modes  of  the  .\G. 
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The  above  aG  'esfin',^  pror-edure  is  aDpiied  'equeiitiaily  ro  ail  Tie  .hG.-:.  he.,  ‘iie 
AG.-s  are  tesred  aie  after  aiiociier  asin;^  sreps  h  Tiron^h  7.  [f  rlie  "esa  :f  ui  .Pfi  hii.--. 
fauit  isolation  is  .^eneraily  to  the  ••onibination  of  Tie  AG  andei-  “esr.  'lie  BILBO 
moduies  associated  with  it.s  [/O.  and  the  inlierent  interconnections. 

Timing  Example 

The  mode  control  signals.  ■Ci".  and  “C3'’,  have  to  be  valid  one  ciock  'ycie 

prior  to  the  parallel  data  at  "dlldTj”.  For  Instance,  parallel  transfer  of  lata  from 
‘■d[i6;li”  to  '‘nut  T6:lP’  and  its  serial  shifting  through  the  "tout"  aotie  involves  the 
timing  sequence  shown  in  Figure  7. 
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tpliil 

!;phi2 


enble 


Cl 

Co 


C.3 


tctrl 


tout 


.As  can  be  inferred  from  Figure  7.  the  control  mode.  "Ci"  =  1.  "Co  "  =  0.  and 
■■C3"  =  1,  is  set  up  one  clock  cycle  before  the  data  at  inpius  is  vaiio.  Th'.- 

parallei  data  at  '‘dflb:!]”  inputs  is  available  at  the  "tout"  node  beginning  at  dock 
cycle  3  in  Figure  7. 

Reference 

[1]  Smith,  J.  E.,  "Measures  of  Effectiveness  of  Fault  Signature  Analysis.”  IEEE  Tran¬ 
sactions  on  Computers  C-29,  no.  6.  .June  1980,  pp.  .510-514. 
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VI  AIN  TEN  AN  CE  NODE 


APPLICATION  NOTE 

Objective  and  Overview 

This  appiicaDion  note  provides  a  funcrional  and  siructurai  description  ot"  a  mainte¬ 
nance  node  (VIN)  nnic  and  illnscrates  its  ase  in  cour, roiling  the  in-system  board  test. 
Maintenance  node  is  an  Interface  moduie  i)erween  a  system-level  test  control  unit 
<  TCL')  and  the  board  under  test,  tts  shown  in  Figure  L. 
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There  are  ten  (10)  signal  lines  between  the  TCU  and  the  MN  ol'  each  board,  as 
shown  in  Figure  '2.  out  of  which  three  ,.3)  are  ciock  signal  iines.  The  TCL'  generates  all 
these  required  ciock  signals  from  a  single  master  ciock  source  present  in  the  TCU.  and 
hence  synchronization  among  the  three  clock  signals  is  easily  accomplished.  The 
required  phase  and ‘  frequency  relationships  among  the  three  clock  signals  are  depen¬ 
dent  on  both  the  system  application  under  consideration  and  the  BIT  technique  used, 
and  they  will  be  addressed  only  to  the  limited  extent  needed  to  clarify  the  presentation 


in  this  application  note. 


Figure  2.  MN-TCU  Interface  Showing  the  Signal  Lines 
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The  functions  of  these  signal  lines  are  illustrated  in  the  foih'jwing  sequence; 

Line  No.  1:  BIT  inoauie  clock  qpai) 

The  TCU  provides  a  clock  signal  v)n  this  line  that  is  processed  by  the  MX  to  deriv*^  wo 
non-overlapping  dock  phases  for  use  by  the  BIT  modules  on  the  board.  The  BIT 
modules  are  assumed  to  have  been  designed  using  a  two-phase  non-overlapping  clock¬ 
ing  methodology. 

Line  No.  2:  Au.xiliary  (test  mode)  system  clock  enable  (aux_enab) 

The  TCU  activates  this  signal  line  if  the  normal  mode  system  clock  is  to  be  dis¬ 
abled  and  an  auxiliary  system  clock  is  to  be  used  for  testing  the  board. 

Line  No.  3:  .Auxiliary  system  clock  (aux_phi) 

The  TCU  provides  a  clock  signal  on  this  line  that  is  processed  by  the  MX’  to 
derive  a  required  number  of  clock  phases  for  use  by  the  logic  on  the  board.  The  phase 
and  frequency  relationships  among  the  inflividual  clock  phases  are  dependent  on  the 
system  design  and  they  are  not  addressed  in  this  application  note.  The  TCU  has  the 
responsibility  of  preserving  the  system-state  by  deactivating  the  auxiliary  clock  (which 
is  generally  accomplished  by  properly  gating  the  clock  signal  generated  within  rhe 
TCU)  for  given  periods  of  time  during  test  when  necessary. 

Line  No.  4:  Control,  data,  and  id  (CDI)  clock  (cdi_phi) 

The  TCU  provides  a  clock  signal  on  this  line  that  is  processed  by  the  MX  to 
derive  two  non-overlapping  clock  phases  for  use  by  certain  registers  of  the  MX  and  of 
the  BIT  modules  on  the  board. 
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Line  No.  5:  BIT  module  control  and  data  In  !cd_in) 

The  TCI'  proviaes  r,he  i-puuired  BIT  nioduie  control  and  data  ui  '  :li^^  ^In.;' 

in  a  bit-serial  format  controlled  by  the  CDI  clock. 

Line  No.  6:  Identification  and  command  input  lid_in) 

The  TCU  provides  an  identification  and  command  code  on  this  line  in  a  bit-seriai 
format  to  enable  a  ^iven  BIT  module  on  the  board  to  accept  BIT  control  and  .lata  slit- 
nals  provided  by  the  TCU.  This  code  also  facilitates  functions  such  as  reset  of  certain 
registers  of  the  MN,  reset  of  the  logic  on  the  board,  and  selective  reset/preset  of  each 
ambiguity  group  (.\G)  output  set. 

Line  No.  7:  Data  out 

The  TCU  receives  test  output  data  from  the  board  on  this  line  in  a  bit-serial  for¬ 
mat  controlled  by  the  CDI  clock. 

Line  Nos.  8,  9,  and  10:  Load  address  inputs  (laddr{2:0]) 

The  TCU  provides  three  address  bits  on  these  lines  to  enable  selective  transfer  of 
BIT  module  control,  data,  and  identification  (id)  related  signals  stored  in  the  MN 
registers  to  the  MN  outputs  on  the  M.N-board  interface.  These  address  bits  also  serve 
to  provide  the  required  enable  signal  for  parallel  latching  of  the  test  output  data  at  the 
MN-board  interface  into  an  MN  internal  register  before  being  serially  transmitted  on 
the  “dataout"  line. 
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Maintenance  Node  Architecture  and  Data  Formats 


.Vn  verai!  )i-ianizacioa  ■)['  'iie  inainreiiaiice  node  is  difv.vn  hi  ri-^vire  :ii.  S-'.'erai 
.■ai'iatioiis  of  diis  oasic  architecture  are  possible  anii  'iiey  iia'.'.-  '.o  bf-  -\'aiuace'i  iii 
specific  simatioiis  wiiere  system.  i)oard.  and  chip  level  design  ieraiis  are  'ompiereiy 
•tnown.  For  instance,  the  auxiliary  clock  phases  may  be  generated  auridn  die  logic  of 
die  ooard  rather  than  in  the  maintenance  node,  and  in  such  a  case,  only  the  auxiliary 
■lock  ana  auxiliary  clock  enaole  signal  lines  .viil  be  iistributed  to  the  logic  on  the 
iioard  rather  than  the  individual  clock  phases.  Furthermore,  integrating  the  MN  logic 
inuo  each  and  every  BIT  module  is  an  option  that  may  be  considered  since  it  reduces 
■  he  interconnection  ■complexity  on  the  board.  The  feasibiiity  of  implementing  this 
option  depends,  however,  on  the  BIT  module  I/O  limitations  and  the  required  versatil¬ 
ity  of  the  designs.  In  this  application  note,  the  specifics  of  the  MN  design  are  chosen 
■^o  that  the  resulting  .VIN  is  compatible  with  the  various  board-ievel  BIT  modules 
designed  at  RTI. 

1)  BIT  Control  and  Data  Register 

The  main  purpose  of  this  register  is  to  provide  the  required  control  and  data  sig¬ 
nals  to  BIT  modules  on  the  board.  This  is  a  16-bIt  register  with  '.i  bit.s  reserved 
for  BIT  module  data  signals  and  12  bits  for  control  signals,  as  shown  in  Figure  d. 
The  remaining  1  bit  may  be  either  left  unused  or  used  in  a  uscr-defned  manner  as 
a  control  signal.  The  datainjoad.  control_load.  MN  reset,  and  CDI  clock  phases 
are  generated  within  the  maintenance  noile.  The  shift  register  contents  are 
transferred  to  CD[l6:l]  outputs  only  when  datain_load  and/or  control_load  signals 
are  high. 
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P'ignrc  3.  An  AroliiLccluift  Tor  Ihc  Maiiil.(;n:iiicc  Node 
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Figure  4.  Control  and  Data  Register  of  the  Maintenance  Node 

Table  1  shows  a  suggested  MN  output  (CD[l5:l])  and  BIT  module  input 
correspondence.  The  BIT  modules  considered  in  the  table  are  the  specific  ones 
that  have  been  described  in  other  application  notes.  Note  that  there  is  consider¬ 
able  flexibility  in  this  assignment,  and  the  choice  in  Table  1  was  made  so  that  cer¬ 
tain  combinations  of  BIT  modules  present  on  a  board  can  be  individually  reset. 
For  instance,  if  the  assignment  in  Table  1  is  used,  “switch”  module  contents  are 
not  affected  when  resetting  the  “scan-set”  BIT  modules  on  the  board,  and  vice 
versa.  Furthermore,  the  MN  output  CD(l]  was  assigned  to  a  BIT  module  data 
input  that  needs  to  be  updated  most  often,  in  order  to  minimize  the  latency  in 
updating  the  data. 
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Table  1.  A  Suggested  MN  Oixtput/BIT  Module  Input  Correspondence 

BIT  MODULE  ON  THE  BOARD 


MN 

TESTING 

EEXOR 

lEXOR 

Anv 

other 

OUTPUT 

SWITCH 

SCAN-SET 

BILBO 

TPG 

TPG 

BIT  Vlodule 

1 

CDfl] 

gendatain 

scanin 

sin 

sdata 

sdata 

CD  [2! 

fbcoefin 

scaninl 

— 

fbin 

fbin 

CD[3j 

sasin 

— 

— 

— 

— 

CDf4] 

reset 

— 

— 

reset 

reset 

CD(5j 

reset 1 

— 

— 

— 

— 

CD16] 

reset2 

— 

— 

— 

— 

CD(71 

genctriin 

— 

— 

— 

— 

CD  [8] 

genshiften 

— 

shiften 

— 

— 

CD  [9] 

saclin 

Cl 

Cl 

fbctrl 

fbctrl 

User- defined 

CD  [10] 

sac2in 

c.. 

Co 

shiften 

shiften 

CD[11] 

sashiften 

— 

C3 

— 

— 

CD[12] 

ctrllin 

— 

reset 

— 

— 

CD[l3i 

ctrlOin 

— 

reset 1 

— 

— 

CD(l4j 

— 

reset 

— 

— 

— 

CD  [15] 

— 

inh 

— 

— 

— 

i 

1)  Tristate  control  inputs 

are  tied  to 

BIT  “enable”  inputs 

1 

J 

2)  —  Unused/User-defined 


2)  Identification  Register  and  the  Associated  Logic 

The  main  purpose  of  this  logic  is  to  determine  whether  or  not  the  board  associ¬ 
ated  with  its  MN  is  being  addressed  by  the  TCU,  and  to  generate  “MN  reset”  and 
“board  reset”  signals.  Generation  of  BIT  module  “enable”  signals  and  AG 
reset/preset  signals  is  assumed  to  be  performed  either  within  the  BIT  modules  or 
by  additional  logic  associated  with  each  AG,  even  though  it  is  controlled  by  the 
MN.  This  assumption  was  made  to  limit  the  output  requirements  of  the  mainte¬ 
nance  node  at  the  MN-board  interface  to  a  reasonable  value. 
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This  logic  consiscs  ol'  inainiy  a  24-bit  shift  register,  two  oomparators.  tmd 
decoder,  as  shown  in  Figure  5.  it  generates  "board  reset."  " 'omp."  inti  "NiN 
reset”  signals  by  comparing  the  selected  bits  of  the  shift  register  witli  -he 
hardwired  identification-  (id)  values  and  by  decoding  the  command  -lode.  All  the 
identification  and  command  codes  from  the  TCU  are  sent  VISE  first.  Bits  I  to  -5 
constitute  the  subsystem  (i.e..  a  collection  of  boards)  id  in  which  the  board  under 
test  is  located;  whereas  the  id  indicated  by  bits  6  to  11  is  that  of  the  board  under 
test.  Hence  the  maintenance  node  in  this  design  can  be  used  to  address  up  to  31 
subsystems  and  63  boards  per  subsystem  (all  zero  id  is  not  used).  Bits  12  to  14 
constitute  the  MN/board  reset  code  as  indicated  in  Table  2. 


Table  2.  MN/Board  Reset  Code 

Bits  14 

13 

12 

Function 

0 

0 

1 

Reset  only  the  MN  associated  with 
the  addressed  board 

0 

1 

0 

Reset  all  boards  in  the  system 

0 

1 

1 

Reset  only  the  addressed  board 

1 

0 

0 

Reset  the  address  board  and  the  MN 
associated  with  it 

1 

0 

1 

Reset  all  MN  in  the  system 

1 

1 

0 

1 

1 

1 

Do  none  of  the  above 

0 

0 

0 
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Board  Beset 


Figure  5.  Identification  and  Command  Code  Shift  l^egisler  and  the  Associated  Logic 


The  id  register  contents  are  transferred  to  the  compare  and  decode  logic  only 
when  the  id_ioad  signal  is  high. 

Bits  15  to  19  constitute  the  AG  identification  code,  whereas  bits  22  to  24  denote 
the  BIT  module  id  corresponding  to  an  addressed  AG.  This  implies  that  the  MN 
in  this  design  can  be  used  to  address  up  to  31  ambiguity  groups  per  board  and  7 
BIT  modules  per  AG.  Bits  20  and  21  form  the  command  code  with  interpretation 
as  shown  in  Table  3. 


Table  3. 

AG  Reset/P  reset  Command  Code 

Bits  21 

20 

F  unction 

0 

1 

Preset  the  addressed  AG  outputs 

1 

0 

Reset  the  addressed  AG  outputs 

1 

1 

Do  none  of  the  above 

0 

0 

Even  though  the  data  associated  with  bits  15  to  24  are  utilized  either  in  the  BIT 
modules  or  in  the  AGs  of  the  board  and  not  in  the  MN  itself,  these  bits  are 
included  in  the  id  shift  register  to  simplify  the  I/O  and  timing  requirements  at  the 
MN-board  interface.  The  logic  associated  with  the  BIT  modules  on  the  board  to 
generate  their  own  “enable”  signals  and  the  AG  reset/preset  signals  is  shown  in 
Figure  6.  If  BIT  modules  do  not  have  this  logic  and  instead  the  “enable”  signal 
line  is  a  primary  input,  then  each  AG  will  have  logic,  as  shown  in  Figure  7,  to  gen¬ 
erate  the  required  “enable”  and  AG  preset/reset  signals. 


Appendix  E-31 


BIT  iiiodiili 

AG  preset  AG  reset  ei»al>le  signa 
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Figure  7.  Logic  Associated  with  the  AGs  to  Generate  the  lte(itiired  'I'esi  Signals 


chitaout 


Note  that  the  AG  preset/reset  ^si^nai  lines  are  to  be  connected  In  an  appropriate 
manner  to  the  preset/reset  inprts  oi'  the  .VGs  on  the  board. 

;>)  Observation  Register 

The  purpose  of  this  register  is  to  convert  the  parallel  test  output  data  avaiiabie  at 
the  MN-board  interface  to  a  .serial  format  for  observation  .at  the  ‘dataout”  'ine  on 
the  iVlN-TGU  interface.  This  is  a  24-bit  register  with  parallel  inputs,  as  shown  in 
Figure  -S. 

MN  inputs 


dataout-load 

1  =  Parallel  input  shift  mode 
0  =  Serial  input  shift  mode 

Figure  8.  The  Observation  Register  in  the  Maintenance  Node  Unit 

The  “dataout_load”  signal,  when  high,  allows  parallel  latching  of  the  inputs  into 
the  observation  register.  When  it  is  low,  the  latched  data  can  be  shifted  out  seri¬ 
ally.  A  suggested  MN  input  (OR[3:l|)  and  BIT  module  output  correspondence  is 
shown  in  Table  4  for  specific  BIT  modules  considered  in  Table  1.  The  MN  input 
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OR[lj  was  assigned  to  a  BIT  module  data  output  that  needs  to  be  monitored  most 
often,  to  minimize  the  latency  in  monitoring  the  data. 


Table  4.  A  Suggested  MN  Input/BIT  Module  Output  Correspondence 

BIT  MODULE  ON  THE  BOARD 


MN 

INPUT 

TESTING 

SWITCH 

SCAN-SET 

BILBO 

EEXOR 

TPG 

lEXOR  Any  Other 
TPG  BIT  Module 

OR[l] 

satout 

scanout 

tout 

tout 

tout  — 

OR[2] 

— 

scanoutl 

— 

fboutl 

fboutl  — 

OR[3l 

— 

— 

— 

Ifoutl 

—  — 

—  =>•  Unused/User-defined 


■4)  Load  Address  Decoder 

The  purpose  of  this  logic  block  is  to  generate  the  required  “idjoad.” 
“datain_load,”  “controljoad.”  and  “dataout_load”  signals.  The  chosen  decode 
scenario  is  shown  in  Table  5. 


Table  5. 

Load  .Address  Decoder  Truth  Table 

control 

datain 

dataout 

id 

Lines  8 

9 

10 

load 

load 

load 

load 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

0 

1 

0 

1 

0 

0 

0 

1 

0 

0 

1 

1 

0 

1 

0 

0 

1 

0 

0 

1 

0 

0 

0 

1 

0 

1 

1 

1 

0 

0 

1 

1 

0 

0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

1 

The  decoding  function  shown  in  Table  o  allows  for  independent  activation  of  each 
load  signal  as  well  as  certain  useful  combinations  of  various  load  signals. 
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Utilization  of  the  Maintenance  Node  in  Controlling  the  In-System  Board 
Test 

This  section  assumes  chat  r,he  board  under  test  utilizes  one  of  the  :bur  boar'i-ieve! 
BIT  techniques  given  below,  implemented  using  the  BIT  modules  described  in  other 
RTI  application  notes.  The  BIT  techniques  considered  are  as  follows; 

1.  Pseudorandom  pattern  application  and  response  compression  technique  using 
either  “BILBO”  or  “Testing-Switch”  modules  that  are  distributed  over  the  board: 

2.  Board-level  scan-set  technique  using  scan-set  BIT  modules  that  are  distributed 
over  the  board: 

3.  Test  point  monitoring  on  a  cycle-by-cycle  basis,  while  applying  either  determinis¬ 
tic  or  pseudorandom  patterns  at  the  board  primary  inputs.  Pseudorandom  pat¬ 
terns  are  assumed  to  be  generated  by  using  the  BIT  modules  such  as  “Testing- 
Switch,”  “BILBO,”  and  other  available  test  pattern  generator  modules: 

4.  Test  point  monitoring  with  compression  of  the  test  output  results,  while  applying 
either  deterministic  or  pseudorandom  patterns  at  the  board  primary  inputs. 
Compression  of  the  test  output  results  is  generally  assumed  to  be  performed  by 
using  “BILBO”  modules  as  parallel  signature  analyzers. 

There  are  numerous  variations  of  implementing  each  of  the  above  BIT  techniques 
on  a  board,  and  consideration  of  all  such  variations  is  beyond  the  scope  of  this  applica¬ 
tion  note.  Hence,  only  certain  specific  implementations  will  be  considered,  and  the  use 
of  the  MN  in  controlling  the  in-system  go/no-go  board  test  will  be  illustrated.  Con¬ 
trolling  the  fault-isolation  tests  to  an  AG  of  the  board  can  also  be  performed  using  the 
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MN.  It  's  t^quivaient  :o  administering  a  ■.•oliectioii  oi'  lo/no-io  rests  'rn  die  inaividuai 
Atis  ■ather  dian  on  die  entire  iioard.  -uu:  in-nc^.  ':mir-d''ilatioii  -viii  >  di' 

separately  considered  in  :  his  seeiion.  One  should  :n;te.  iiowe'/er.  diar  :':inir-is(>i;u ion 
tests  are  ^eneraily  nen'ormed  oniy  alter  the  deiective  iioardisi  isiare;  oiKen  out  :■{  rue 
system,  and  they  may  be  controileri  by  the  ATE  rather  dian  the  system  ievei  TC'd 

Example  1 

Consider  a  board  consisting  of  three  ambiguity  groups  of  oiiips  and  using  the 
pseudorandom  pattern  application  and  response  compression  BIT  technique  dnpie- 
mented  using  the  "testing-switcli"  modules,  as  shown  in  Figure  0.  For  ietails  on  the 
"testing-switch"  modtiies  and  how  to  use  them  in  a  design,  the  reader  is  referred  to 
the  relevant  application  note.  Even  though  a  go/no-go  test  is  the  subject  of  this  exam¬ 
ple,  Figure  9  also  shows  the  test  logic  incorporated  to  perform  fanh-isoiation  to  an  AG 
for  off-the-system  board  maintenance  purposes. 

It  is  assumed  that  the  switch  modules  have  internal  ■‘enable”  generation  iogic 
shown  in  Figure  6,  and  the  .\G  ‘‘reset"  and  "preset"  signals  in  Figure  fi  fan  be  used  to 
reset  and  preset  each  .\G  output  set  independently  of  another  .\G  if  necessary.  The 
connections  indicated  in  Tables  1  and  I  are  a.ssiimed  to  have  been  made  between  each 
of  the  switch  modules  and  the  .MN  I/O  at  the  MN-board  interface.  The  AGs  are 
assumed  to  be  synchronous  in  general,  even  though  portions  of  asynchronous  logic  can 
also  be  handled.  The  system  clock  is  wired  such  that  when  the  "auxiliary  clock 
enable"  line  is  activated  it  is  disabled  and  the  auxiliary  clock  controls  the  board  opera¬ 
tion.  It  is  further  assumed  that  whenever  the  auxiliary  system  clock  is  held  at  low 
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Figure  9.  A  Board  Using  the  ■‘Testing-Switch"  BIT  Modules 

level  and  the  AG  reset/preset  signals  are  not  active,  the  AGs  retain  their  pn-vicMis 
state  indefinitely.  .-V  sintilar  assumption  holds  for  the  BIT  modules  on  the  hoard  as 
well.  Finally,  a  BIT  module-AG  assignment  shown  in  Table  G  is  assnnual  for  the  j  iir- 
pose  of  controlling  the  test. 


Table  6:  A  BIT  Moduie-AG 

.-Vssignment  for  the  Network  in  Figure  9  ' 

Bit  Module(s) 

Assigned  AG  1 

SVV-1  and  SVV-.a 

AG-1  1 

SW-2 

AG-2  j 

S\V-.3  and  SW-I 

AG-.3  1 
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A  Procedure  for  Administering  a  Go/No-go  Test  of  the  Board  in  Example  1 


The  following  .sreps  are  generally  performed  by  r,he  system  level  TCh'.  Ste;''  1 
and  2  are  preliminary  steps  that  ensure  proper  clock  control  and  MN  and  boai'd  reset 
before  the  actual  tests  can  be  performed.  Steps  3  to  12  accomplish  the  switch  module 
testing,  while  steps  13  to  16  set  up  the  board  for  a  go/ no-go  test.  The  test  vectors  gen¬ 
erated  by  the  relevant  switch  modules  are  applied  to  the  board  and  the  output  results 
are  compressed  into  signatures  in  step  17.  Finally,  comparison  of  the  actual  signatures 
with  the  expected  ones  and  determining  the  status  of  the  board  are  accomplished  in 
step  18.  Further  details  on  how  these  steps  are  performed  are  provided  in  the  follow¬ 
ing  paragraphs. 

1.  Activate  the  “auxiliary  clock  enable”  line  and  hold  the  auxiliary  clock  and  BIT 
clock  lines  at  low  level  by  proper  gating  of  the  clock  signals  generated  within  the 
TCU. 

2.  Shift  in  a  2‘4-bit  id  and  command  word  containing  the  appropriate  o-bit  subsys¬ 
tem  id,  6-bit  board  id,  3-bit  command  code  indicating  the  specific  MN  and  board 
reset,  and  2-bit  AG  reset/preset  code  corresponding  to  no  AG  reset  or  preset. 
This  word  has  to  be  shifted  in  through  “id_in”  input  under  the  control  of  GDI 
clock.  Arbitrary  values  may  be  used  for  the  .5-bit  AG  id  and  the  3-bit  BIT  mof'ule 
id  for  this  step.  After  24  GDI  clock  cycles,  apply  the  load  address  bits  such  that 
only  the  “id_load’'  signal  is  high  for  one  GDI  clock  cycle.  This  step  ensures  that 
the  necessary  MN  and  board  reset  is  accomplished.  Raise  the  “dataoiitjoad"  sig¬ 
nal  to  high  level,  which  configures  the  observation  register  in  the  M.N  to  a 
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parallel-latch  mode  of  operation  for  one  CDI  clock  cycle.  Then  serially  shift  out 
the  register  contents  ("dacaouc_load"  =  0)  and  verify  the  MN  and  board  resc 
bits  that  appear  on  the  ‘■'dataout'’  line  at  the  MX-TCU  interface. 

3.  Repeat  step  2  with  another  2-t-bit  word  containing  the  3-bit  command  code  to 
deactivate  the  MN  and  board  reset  signals.  Also,  the  o-bit  AG  id  corresponding 
to  a  given  AG  and  the  3-BIT  module  id  corresponding  to  a  given  switch  are  used 
in  the  24-bit  word.  This  step  results  in  the  “enable"  of  a  given  switch  module 
being  high,  which  in  turn  sets  up  the  switch  to  receiv^e  control  and  data  signals 
from  the  MN. 

4.  Shift  in  a  16-bit  control  and  data  word  through  the  “BIT  control  and  data"  line 
containing  all  zeros  except  “reset”  s=  1  and  “resetl”  =  1.  .\fter  16  CDI  clock 
cycles,  raise  the  “controljoad”  and  “datain_load”  signals  to  high  level  for  one 
CDI  clock  cycle.  This  step  ensures  that  the  reset  of  all  the  switch  modules  on  the 
board  is  accomplished, 

5.  Repeat  step  4  with  another  16-bit  word  containing  all  zeros  except  “ctrllin”  =  1 
and  “ctrlOin"  =  1  to  enable  a  test  path  within  the  chosen  switch  module.  Then 
apply  the  BIT  module  clock  for  one  clock  cycle  so  that  the  control  signals  are 
latched  in  the  chosen  switch. 

6.  Shift  in  16-bit  control  and  data  words  containing  the  appropriate  control  and  data 
bits  required  for  initialization  of  the  test  pattern  generator  and  the  signature 
analyzer  within  the  chosen  switch.  The  initialization  process  consists  of  repeated 
shifting  in  of  a  16-bit  word,  raising  “controljoad"  and/or  “datainjoad"  signals 
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r,o  high  level  tor  oae  CDl  cioci':  (*ycte  after  every  16  CD!  eiock  '’vcies.  end  aopivius; 
rile  BIT  inoiiule  '-lock  ror  jue  i-iock  eyvie.  At  rlie  end  of  tlie  iuiriaiization  pro  -!-'-, 
the  signarure  analyzer  in  v.iie  -diosen  awitch  Is  conri^nred  for  oarnilei  dara 
eompressioa  mode  of  operacion  (■‘saclin  '  =  I  and  “sac^ia”  =  Li. 

Repeat  step  3  with  "all  zero”  BIT  module  id.  which  results  in  the  "enable''  of  the 
chosen  switch  being  low.  The  purpose  of  this  step  is  to  prevent  further  alteration 
of  the  latched  control  signals  in  the  chosen  switch. 


S.  Apply  the  BIT  clock  for  a  predetermined  number  of  clock  cycles.  During  this 
step,  the  test  patterns  generated  in  the  switch  are  compressed  by  the  signature 
analyzer  within  the  switch.  .\t  the  end  of  this  step,  hold  the  BIT  clock  at  low 
level  by  proper  gating  of  the  clock  signal. 

9.  Repeat  step  4  with  '‘resetl”  =  1  (‘'reset'’  =  0).  This  step  disables  shifting  in  all 
the  signature  analyzers  of  the  switches  and  thus  locks  the  resulting  sign-ature  in 
the  chosen  switch. 

10.  Repeat  step  3  with  the  -appropriate  id.  which  results  in  the  ‘‘enable”  of  the  chosen 
switch  being  high. 

11.  Repeat  step  4  with  ‘‘sashiften"  =  1  and  ‘‘sac2in'’  =  1  (all  other  bits  zero).  This 
action  enables  serial  shifting  in  the  signature  analyzer  of  the  chosen  switch.  Raise 
the  '■dataout_load”  signal  to  high  level.  Then  apply  the  BIT  clock  in  synchrony 
with  the  CDI  clock.  Under  this  mode,  the  '‘satout'’  output  of  the  chosen  switch  Is 
connected  to  the  '‘dataout'’  line  with  one  CDI  clock  cycle  latency.  Monitor  the 
signature  at  the  "dataout"  line  and  compare  it  with  the  expected  one.  obtained  a 


I 
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priori  from  sirauiaLion. 
'xteai.  Ar  Ale  end  of 


This  step 


'.-■hecks  the  functionality  of  the  .'’vvitch  co  a  zood 


This  step,  lioid  the  BIT  '•ioci-c  at  iow  Tvrd  is'  -proper  patina 


)f  Aie  -loid-:  signal. 


12.  xRepeat  steps  -i  to  il  enough  number  of  times  -vith  the  5-bic  .\G  id  and  the  o-bic 
BIT  module  id.  so  cho.sen  as  to  complete  the  testing  of  all  the  s/ivitch  modules  on 
the  board. 

13.  Repe-at  step  -t  so  that  all  the  switch  modules  -are  reset  again.  This  step  ensures 
that  all  the  .switches  on  the  board  are  in  normal  "pass  through"  mode  of  opera¬ 
tion. 


14.  Repeat  step  3  and  step  (>  with  the  o-bit  .4.0  id  corresponding  to  .\G-1  and  the  3- 
bit  BIT  module  Id  corresponding  to  SW-1.  At  the  end  of  this  step,  the  test  pat¬ 
tern  generator  in  SW-1  will  be  configured  to  supply  pseudorandom  test  vectors  to 
AG-1  primary  Inputs. 

15.  Repeat  step  3  and  step  6  with  the  o-bit  .\G  id  corresponding  to  .-\.G-3  and  the  BIT 
module  id  corresponding  to  SW-4.  At  the  end  of  this  step,  the  signature  analyzer 
in  SW-4  will  be  configured  to  accept  .A.G-3  primary  outputs  for  data  compression. 

16.  Repeat  step  7  to  bring  the  "enable”  of  SW-4  to  low  level. 

17.  Apply  the  BIT  clock  and  the  auxiliary  system  clock  in  synchrony  for  a  predeter¬ 
mined  number  of  clock  cycles.  During  this  step,  pseudorandom  vectors  generated 
in  SW-1  are  applied  to  .\G-1  primary  inputs,  and  .\G-3  primary  outputs  are 
compressed  in  SW-4.  At  the  end  of  this  step,  hold  the  BIT  clock  and  the  auxiliary 
system  clock  at  low  level  by  proper  gating  of  the  clock  signals. 


Appendix  E-42 


18.  Repeat  steps  9  to  11  with  the  5-bit  AG  id  corresponding  to  AG-3  and  the  o-oit 

BIT  module  id  corresponding  to  SW-4.  and  determine  the  status  oi  the  board. 

.-\.n  incorrect  signature  in  SW-4  at  the  end  of  step  18  indicates  a  faulty  boai-'i. 
while  a  correct  signature  in  general  implies  a  non-faulty  board.  However,  the  entire 
test  procedure  may  have  to  be  repeated  several  times  and  the  consistency  of  the  results 
must  be  verified  to  ensure  high  test  confidence.  Furthermore,  there  may  be  a  need  for 
performing  additional  tests  involving  multiple  boards  to  completely  check  the  intercon¬ 
nections  between  the  board  under  test  and  the  other  boards.  However,  administering 
these  additional  tests  differs  from  the  above  test  procedure  only  in  the  id  values  that 
need  to  be  used  in  different  steps  for  the  board,  AG,  and  the  BIT  modules.  It  mainly 
involves  configuring  the  switch  modules  on  the  periphery  of  the  boards  to  either  the 
test  pattern  generator  or  signature  analyzer  mode  of  operation,  applying  the  BIT  clock 
and/or  auxiliary  system  clock  for  a  predetermined  number  of  clock  cycles,  and  verify¬ 
ing  the  relevant  signatures  as  already  illustrated  in  the  above  test  procedure  for  a  sin¬ 
gle  board. 
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Example  2 


Consider  a  board  consisting  of  three  ambiguity  groups  of  chips  and  using  ^  iic 
board-level  scan-set  BIT  technique,  implemented  using  the  scan-set  BIT  modules  as 
shown  in  Figure  10.  For  details  on  the  scan-set  BIT  modules  and  how  to  use  them  in  a 
design,  the  reader  is  referred  to  the  relevant  application  note.  Even  though  a  go/no-go 
test  is  the  subject  of  this  example.  Figure  10  also  shows  the  test  logic  incorporated  to 
perform  fault- isolation  to  an  AG  for  off-the-system  board  maintenance  purposes. 


r 


Figure  10.  A  Board  Using  the  Scan-Set  BIT  Modules 
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It  is  assumea  tnat  tiie  scaii-sec  modules  iiavm  incernai  ■■enai)ie''  generation  osic 
rliown  in  Figure  6.  ana  the  AG  reset  and  preset  .dgnais  in  Figure  f)  -an  ue  'iseci  ro  r-^sec 
ana  preset  each  AG  output  set  lndepen<iently  oi'  anotnor  AG  ii’  ne''e,':sary.  The  .■rninec- 
tions  indicated  In  Tables  i  and  4  are  assumed  to  have  been  made  between  eacii  ot’  tlie 
scan-set  modules  and  the  AIN  I/O  at  the  .VIN-board  interface.  The  AGs  are  mssumed 
to  be  synchronous  in  general,  even  though  portions  of  asynchronous  logic  can  also  be 
handled.  The  system  clock  is  wired  such  that  when  the  “au.Kiliary  clock  enable  "  line  is 
activated,  it  is  disabled,  and  the  auxiliary  clock  controls  the  board  operation.  It  is 
further  assumed  that  whenever  the  auxiliary  system  clock  is  held  at  low  level  and  the 
.\G  reset/preset  signals  are  not  active,  the  .\Gs  retain  their  previous  state  indefinitely. 
.V  similar  assumption  holds  for  the  BIT  modules  on  the  board  as  well.  Finally,  a  BIT 
module-.-\G  assignment  shown  in  Table  7  is  assumed  for  the  purpose  of  controlling  the 
test. 


Table  7.  .A  BIT  Module-AG  .Assignment 
_ for  the  .Metwork  in  Figure  10 _ 

BIT  Module(s)  Assigned  AG 

I  SS-1  and  SS-2  .AG-1 

I  SS-.3  AG-2 

I  SS-4 _ .AG-3 


A  Procedure  for  Administering  a  Go/No-go  Test  of  the  Board  in  Example  2 

The  following  steps  are  generally  performed  by  the  system  level  TCU.  Steps  1 
and  2  are  preliminary  steps  that  ensure  proper  clock  control  and  MN  and  hoard  reset 
before  the  actual  tests  can  be  performed.  Steps  3  to  6  accomplish  the  scan-'^et  BIT 
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'.nodule  tests,  wdlie  steos  7  to  LO  r-aeiiitaie  scauninit-in  ami  seiriuu  'vd  ii 


iesired 


rest  i)utte!'n  and  appiving  It  :o  die  Doaro.  .steps 


Id  icetnnpiisii  -ea.ii-'-ur  m'  die 


noar'i  respon.se  ami  ‘omparisun  .virdi  the  eKpeereu  -espouse,  r'diaily.  'ten  I  i  •'■muie! 
tbe  test  oy  repeatin'^  tlie  needed  earlier  siep.s  '.vich  a  .siilTicienr,  tuininer  oi  test  v'eetor.s. 

i.  Activate  the  ‘auxiliary  clock  -‘nahle''  line,  and  hold  the  auxiliary  system  ••lock  :in<l 
BIT  clock  lines  at  low  lea’ei  by  property  ^atin^  the  clock  signals  generated  '.vithin 
the  TCr. 

‘2.  Shift  in  a  24-bit  id  and  command  word  containing  the  appropriate  -o-bit  subsys¬ 
tem  id.  6-bIi  board  Id.  3-bIt  command  code  indicating  the  specific  MN  and  board 
reset,  and  ‘J-bit  .\G  reset/preset  code  corresponding  to  no  .VC  reset  or  preset. 
This  word  has  to  be  shifted  in  through  "id_in‘’  input  under  the  control  of  CD! 
clock.  .A-rbitrary  values  may  be  used  for  the  .5-bit  .\G  id  and  the  3-bit  BIT  module 
id  for  this  step.  .After  24  GDI  dock  cycles,  apply  the  load  address  bits  such  that 
only  the  “id_load”  signal  is  high  for  one  CDI  clock  cycle.  This  step  ensures  that 
the  necessary  MN  and  board  re.set  is  accomplished.  Raise  the  ”dataout_load"  sig¬ 
nal  to  high  level,  which  configures  the  observation  register  in  the  MN  to  a 
parallel-latch  mode  of  operation  for  one  CDI  dock  cycle.  Then  serially  shift  out 
the  register  contents  (‘■dataout_load”  =  0)  and  verify  the  MN  and  board  reset 
bits  that  appear  on  the  “dataout’’  line  at  the  MN-TCl'  interface. 


3.  Repeat  step  2  with  another  ‘id-bit  word  containing  the  3-bir,  command  code  to 
deactivate  the  MN  and  board  reset  signals.  Also,  the  -a-bit  AG  id  corresponding 
to  a  given  AG  and  the  3-bit  BIT  module  i<l  corresponding  to  a  given  scan-set 
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moduie  are  used  in  the  2-1-bit  word.  This  step  results  in  the  "enable"  of  the 
chosen  scan-set  BIT  moduie  being  high,  which  in  turn  sets  it  up  to  receive  coiund 
signals  from  the  MN. 

-1.  Shift  in  a  16-bit  control  and  data  word  through  the  "BIT  control  and  data"  line 
containing  all  zeros  except  ‘‘reset”  =  1.  After  16  CDI  clock  cycles,  raise  the 
"controljoad”  and  ‘‘datainjoad”  signals  to  high  level  for  one  CDI  clock  cycle. 
This  step  ensures  that  the  reset  of  all  the  scan-set  BIT  modules  on  the  board  is 
accomplished.  Repeat  this  step  with  “reset”  =  0  to  deactivate  the  BIT  module 
reset  signal. 

5.  Apply  the  load  address  bits  so  that  ‘‘datain_load”  and  “dataout_load”  signals  are 
at  high  level.  Shift  in  data  through  “BIT  control  and  data”  input  under  the  con¬ 
trol  of  CDI  clock.  Apply  the  BIT  clock  in  synchrony  with  the  CDI  clock.  Under 
this  mode,  “scanout”  output  of  the  chosen  scan-set  module  is  connected  to  the 
‘‘dataout”  line  at  the  MN-TCU  interface  with  one  CDI  clock  cycle  latency.  The 
output  bit  stream  at  “dataout”  should  follow  the  input  bit  stream  with  a  known 
latency.  This  step  checks  the  functionality  of  the  scan-set  module  to  a  good 
extent.  At  the  end  of  this  step,  hold  the  BIT  clock  at  low  level  by  proper  gating 
of  the  clock  and  modify  the  load  address  bits  so  that  all  load  signals  are  at  low 
level. 

6.  Repeat  steps  3  to  5  enough  number  of  times  with  the  .>bit  AG  id  and  the  3-bit 
BIT  module  id.  so  chosen  as  to  complete  the  testing  of  all  the  scan-set  modules  on 
the  board. 
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7.  Repeat  step  4  so  that  all  the  scan-set  modules  are  reset.  This  step  ensures  that 
they  are  in  normal  "pass  through”  mode  of  operation  . 

8.  Repeat  step  3  vvith  the  o-bit  AG  id  corresponding  to  AG-1  and  the  3-bit  BIT 
module  id  corresponding  to  SS-1. 

9.  Shift  in  a  16-bit  control  and  data  word  containing  all  zeros  except  “co”  =  1. 
.Alter  16  GDI  clock  cycles,  raise  the  “control_load”  signal  to  high  level  for  one  GDI 
clock  cycle.  Then  apply  the  BIT  clock  for  one  clock  cycle  so  that  the  control  sig¬ 
nals  are  latched  In  the  chosen  scan-set  module. 

10.  Raise  the  “datain_load”  signal  to  high  level  by  proper  application  of  the  load 
address  bits.  Shift  in  the  desired  test  vector  through  “BIT  control  and  data” 
input  while  applying  GDI  and  BIT  clocks  in  synchrony.  After  a  predetermined 
number  of  GDI  clock  cycles,  the  test  vector  will  be  available  at  the  “uutin”  out¬ 
puts  of  the  SS-1  module  for  parallel  application  to  AG-1  primary  inputs.  Then 
apply  the  auxiliary  system  clock  for  one  clock  cycle.  Hold  both  the  auxiliary  and 
the  BIT  clocks  at  low  level  at  the  end  of  this  step  by  properly  gating  the  clock  sig¬ 
nals. 

11.  Repeat  step  3  with  the  5-bit  AG  id  corresponding  to  AG-3  and  the  3-bit  BIT 
module  id  corresponding  to  SS-4. 

12.  Repeat  step  9  with  “cj”  =  1  (“co”  =  0).  This  step  enables  parallel  latching  of  the 
AG-3  primary  outputs  into  SS-4. 

13.  Repeat  step  9  with  all  zero  16-bit  word.  Raise  “dataoutjoad”  signal  to  high  level, 
and  apply  the  BIT  clock  in  synchrony  with  the  GDI  clock.  This  step  reconfigures 
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SS-4  inr.o  seriai-siiii't  mode  d'  ^jperatioa.  and  rlie  '‘scanoiu  ’  output  >i'  oo—t  is  ./'.'u- 
Liecrud  ro  die  "  iacaoiir/'  ;ine  -it,  the  XiN-TCT  uirprt'ace  -.vitii  ;[ip  ' 'Dl  -iopic  'y  -ie 
latency.  Mouitoi*  'he  output  data  at  die  "dataout"  line  I'or  a  preueterniiueil 
number  <)t‘  CD!  clock  cycles,  and  compare  It  tvith  r.he  e.'tpecteu  result.  Hold  die 
BIT  clock  at  low  level  at  tlie  ena  of  r.his  step  by  properly  gatim;  the  'dock. 

1-4.  Repeat  steps  S  to  13  enough  number  of  times  with  different  test  vectors,  and 
determine  the  status  of  the  board. 

.\n  incorrect  output  on  the  “dataout’'  line  in  step  14  indicates  a  faulty  board, 
while  correct  outputs  throughout  step  14  generally  Imply  a  iion-faulty  board.  How¬ 
ever.  the  entire  test  procedure  may  have  to  be  repeated  .several  times  and  the  con¬ 
sistency  of  the  results  must  be  verified  to  ensure  test  confidence.  Further,  ore.  there 
may  be  a  need  for  performing  additional  tests  involving  multiple  boards  to  completely 
check  the  interconnections  between  the  board  under  test  and  the  other  boards.  How¬ 
ever,  administering  these  additional  tests  differs  from  the  above  test  procedure  only  in 
the  id  values  that  need  to  be  used  in  different  steps  for  the  board,  the  .\G.  and  the 
scan-set  BIT  modules. 
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Example  3 


Consider  -i  i'jOMrd  '"ousisr.ing  of  rlirt-e  ;>inr)igiiiry  ^ronos  -jf  ohips  uiu  isin'^ 
by-cyrde  resr,  point  nioniroring  :is  die  BIT  reetiniqiie.  Tesr  point  aionicoi-ing  :s  issniuf-'i 
to  be  performed  by  using  rdie  scan-set  BIT  modules,  and  pseudorandom  patterns  gen¬ 
erated  by  a  BILBO  module  are  applied  to  AG-L  primary  inputs  :as  shown  in  Figure  11. 
For  details  on  the  individual  BIT  modules  and  how  to  use  them  in  a  design,  the  reader 
is  referred  to  the  relevant  application  note.  Ev'en  though  a  go/no-go  test  is  the  subject 
of  this  example.  Figure  11  also  shows  the  test  logic  Incorporated  to  perform  fault- 
isolation  to  an  AG  for  off-the-system  board  maintenance  purposes. 

It  is  assumed  that  the  BILBO  and  the  scan-set  BIT  modules  have  internal 
■‘enable”  generation  logic  shown  in  Figure  6,  and  the  AG  reset  and  preset  signals  in 
Figure  6  can  be  used  to  reset  and  preset  each  .\G  output  set  independently  of  another 
AG  if  necessary.  The  connections  indicated  in  Tables  1  and  4  are  assumed  to  have 
been  made  between  each  of  the  BIT  modules  and  the  MN  I/O  at  the  MN-board  inter¬ 
face.  An  MN  output  that  was  not  assigned  to  any  of  the  BIT  modules  on  the  board 
needs  to  be  assigned  to  the  "muxctrl”  input  of  the  multiplexer,  and  ■‘CDfS]'’  output  of 
the  MN  was  arbitrarily  chosen  to  be  connected  to  the  “muxctiT’  input. 

The  AGs  are  assumed  to  be  synchronous  in  general,  even  though  portions  of  asyn¬ 
chronous  logic  can  also  be  handled.  The  system  clock  is  wired  such  that  when  the 
“auxiliary  clock  enable”  line  is  activated,  it  is  disabled,  and  the  auxiliary  clock  controls 
the  board  operation.  It  is  further  assumed  that  whenever  the  auxiliary  system  clock  is 
held  at  low  level  and  the  .\G  reset/preset  signals  are  not  active,  the  .\Gs  retain  their 
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muxccrl 


Figure  11.  A  Board  Using  the  Cycle-by-Cycle  Test  Point  Monitoring  BIT  Technique 


previous  state  indefinitely.  A  similar  assumption  holds  for  the  BIT  modules  on  the 
board  as  well.  Finally,  a  BIT  module- AG  assignment  shown  in  Table  8  is  assumed  for 
the  purpose  of  controlling  the  test. 


Table  8.  A  BIT  Module-AG  Assignment 

for  the  Network  in  Figure  11 

Bit  Module 

Assigned  AG 

BILBO 

AG-1 

SS-1 

AG-2 

SS-2 

AG-.3 
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A  Procedure  for  Administering  Go/No-go  Test  of  the  Board  in  Example  3 


The  following  steps  are  generally  performed  by  the  system  level  TCT,'.  Sfep"  3  f 
6  accomplish  the  scan-set  BIT  module  testing,  whereas  steps  7  to  12  test  the  fnncticns 
of  the  BILBO  module.  Application  of  the  test  vector  generated  by  the  BILBO  to  the 
board  is  accomplished  in  steps  13  to  15,  while  step  16  facilitates  the  comparison  of  the 
actual  board  response  to  the  expected  response.  Steps  17  through  19  reconfigure  the 
BILBO  to  generate  the  next  test  vector.  Finally,  step  20  completes  the  test  b\'  repeat¬ 
ing  the  needed  earlier  steps  enough  number  of  times  so  that  a  sufficient  number  of  test 
vectors  generated  by  the  BILBO  are  applied  to  the  board  and  the  results  are  verified. 

1.  Activate  the  "‘auxiliary  clock  enable’dine.  and  hold  the  auxiliary  system  clock  and 
BIT  clock  lines  at  low  level  by  properly  gating  the  clock  signals  generated  within 
the  TCU. 

2.  Shift  in  a  24-bit  id  and  command  word  containing  the  appropriate  5-bit  subsys¬ 
tem  id,  6-bit  board  id,  3-bit  command  code  indicating  the  specific  MN  and  board 
reset,  and  2-bit  AG  reset/preset  code  corresponding  to  no  .\G  reset  or  preset. 
This  word  has  to  be  shifted  in  through  “id_in”  input  under  the  control  of  GDI 
clock.  Arbitrary  values  may  be  used  for  the  5-bit  AG  id  and  the  3-bit  BIT  module 
id  for  this  step.  .After  24  GDI  clock  cycles,  apply  the  load  address  bits  such  that 
only  the  “idjoad”  signal  is  high  for  one  GDI  clock  cycle.  This  step  ensures  that 
the  necessary  MN  and  board  reset  is  accomplished.  Raise  the  ■‘dataoutjoad"  sig¬ 
nal  to  high  levTl,  which  configures  the  observation  register  in  the  MN  to  a 
parallel-latch  mode  of  operation  for  one  GDI  clock  cycle.  Then  serially  shift  out 
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rhe  regisoer  fonceiics  i  ■■'iar.aouc_ioad"  =  0)  and  verify  riie  IdX  ina  noaru 
i'/irs  cliac  appear  a'ti  rue  "  latac'-ur”  ane  ax  the  MN-T(''f/  Interlace. 

Repeat  step  2  with  another  24-bit  word  containing  riie  h-oir  'roramand  •■ode  "o 
deactivate  the  MN  and  i)oard  reset  signais.  Also,  the  o-bit  AG  ai  corresporioing 
to  .AG-2  and  the  2-bit  BIT  moduie  id  corresponding  to  SS-l  are  used  in  rhe  24-bit 
w'ord.  This  step  results  in  the  ■'enable  "  of  SS-1  being  high,  which  in  tum  sets  it 
up  to  receive  control  signals  from  the  VIN. 

4.  Shift  in  a  16-bit  control  and  data  word  through  “BIT  control  and  data"  input 
containing  all  zeros  except  ’Teset”  =  1  and  “resetl"  =  1.  .After  16  GDI  clock 
cycles,  raise  the  "controljoad”  and  "datainjoad"  signals  to  high  level  for  one 
GDI  clock  cycle.  This  step  ensures  that  the  reset  of  all  the  BIT  modules  on  the 
board  Is  accomplished.  Repeat  this  step  with  “reset"  =  0  and  ‘‘resetl”  =  0  to 
deactivate  the  BIT  module  reset  signals. 

5.  Apply  the  load  address  bits  so  that  the  "datain_load”  and  ‘'dataoutjoad”  signals 
are  at  high  level.  Shift  in  data  through  "BIT  control  and  data”  input  under  the 
control  of  GDI  clock.  .Apply  the  BIT  clock  in  synchrony  with  the  GDI  clock.  The 
output  bit  stream  at  “dataout"  line  should  follow  the  input  bit  stream  with  a 
known  latency.  This  step  checks  the  functionality  of  the  chosen  scan-set  module 
to  a  good  extent.  .-Vt  the  end  of  this  step,  hold  the  BIT  module  clock  at  low  level 
by  properly  gating  the  clock  and  modify  the  load  address  hits  such  that  ail  load 
signals  are  at  low  level. 
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6.  Repeac  steps  o  to  o  enough  numoer  ot'  times  with  tiie  o-'oit  AG  id  ;ind  the  h-oit 

BIT  niociiiie  id.  so  idiosen  :is  to  oompiete  the  testing  'U'  ail  die  -a:-:iii--'et  :no<iuies  )ii 

die  board. 

7.  Repeat  step  4  so  that  all  the  BIT  modules  are  again  reset. 

S.  Repeat  step  3  with  the  5-hit  AG  id  corresponding  to  AG-1  and  the  BIT  raoaule  hi 

corresponding  to  the  BILBO. 

Q.  Shift  in  a  16-bit  control  and  data  word  containing  all  zeros  except  "shiften"  =  1 
and  “c.i”  =  1.  .After  16  GDI  clock  cycles,  raise  the  ■h;ontrol_load'’  and 
■‘datain_load”  signals  to  high  level  for  one  GDI  clock  cycle.  Then  apply  the  BIT 
clock  For  one  clock  cycle.  This  step  enables  serial  shifting  of  data  in  the  BILBO. 

10.  Repeat  step  o.  Under  this  mode,  "tout"  output  of  the  BILBO  is  connected  to  the 

■‘dataout"  line  at  the  AIN-TCU  interface  with  one  GDI  clock  cycle  latency.  Simi¬ 

larly.  the  "BIT  control  and  data"  line  is  connected  to  the  ‘‘sin”  input  of  the 
BILBO  with  one  GDI  clock  cycle  latency.  This  step  checks  the  serial  shifting 
function  of  the  BILBO. 

11.  Repeat  step  9  with  “shiften"  =  1.  ‘‘C|"  =  1.  and  "Co"  =  1.  This  step  enables  rhe 
test  pattern  generator  mode  of  the  BILBO. 

12.  Raise  the  ‘‘dataoutjoad”  signal  to  high  level.  Apply  the  BIT  clock  in  synchrony 
with  the  GDI  clock.  Under  this  mode,  the  output  on  the  ‘‘dataout”  line  .should 
match  the  pr^-computed  values  obtained  from  simulation  of  the  BILBO.  This  step 
generally  assumes  that  the  BILBO  has  a  non-zero  output  vector  at  its  "out”  port 
at  the  eml  of  stop  11.  Kohl  the  BIT  clock  at  low  level  at  the  end  nf  tbi.s  step  by 
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properly  gating  the  clock. 


1.3.  Shift  in  a  16-bit  control  and  data  word  containing  ail  zeros  except  '•resetl"  =  1. 
-\l“ter  16  CDI  clock  cycles,  raise  the  "controMoad”  and  "datainjoad’'  signals  to 
high  level  for  one  CDI  clock  cycle.  This  step  disables  shifting  in  the  BILBO  dur¬ 
ing  the  time  when  AG-3  primary  outputs  will  be  scanned  out  through  the  SS-2 
module.  Repeat  this  step  with  '"cj”  =  1  (“resetl”  =  0). 

14.  Repeat  step  3  with  the  5-bit  AG  id  corresponding  to  AG-3  and  the  3-bit  BIT 
module  id  corresponding  to  SS-2. 

15.  Apply  the  auxiliary  system  clock  for  one  clock  cycle.  Then,  apply  the  BIT  clock 
for  one  clock  cycle.  During  this  step,  the  test  vector  generated  by  the  BILBO  gets 
applied  to  AG-1  primary  inputs  and  the  board  state  changes.  Furthermore,  the 
SS-2  module  is  configured  to  accept  AG-3  primary  outputs  in  parallel. 

16.  Raise  the  “dataout_load”  signal  to  high  level.  Repeat  step  9  with  all  zero  16-bit 
control  and  data  word,  and  apply  the  BIT  module  clock  in  synchrony  with  the 
CDI  clock.  This  step  reconfigures  SS-2  to  serial-shift  mode  of  operation  after 
parallel-latching  of  AG-3  primary  outputs.  Monitor  the  output  data  at  the 
“dataout”  line  for  a  predetermined  number  of  CDI  clock  cycles  and  compare  it 
with  the  expected  result.  Hold  the  BIT  clock  at  low  level  at  the  end  of  this  step 
by  properly  gating  the  clock  signal. 

17.  Repeat  step  3  with  the  5-bit  AG  id  corresponding  to  AG-1  and  the  .3-bit  BIT 
module  id  corresponding  to  the  BILBO. 
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18.  Repeat  step  9  with  “shiften"  =  1.  “ci"  =  1,  and  ‘’Co"  =  1. 

19.  Apply  the  BIT  clock  for  one  clock  cycle.  At  the  end  of  this  step,  a  differem  re'-t 
vector  will  he  available  at  the  "out”  port  of  the  BILBO. 

"20.  Repeat  steps  1.3  to  19  a  predetermined  number  of  times  and  determine  the  status 
of  the  board. 

An  Incorrect  output  at  the  "‘dataout”  line  in  step  20  indicates  a  faulty  board, 
while  correct  outputs  throughout  step  20  generally  imply  a  non-faulty  board.  How¬ 
ever.  the  entire  test  procedure  may  have  to  be  repeated  several  times  and  the  con¬ 
sistency  of  the  results  must  be  verified  to  ensure  test  confidence.  Furthermore,  there 
may  be  a  need  for  performing  additional  tests  involving  multiple  boards  to  completely 
check  the  interconnections  between  the  board  under  test  and  the  other  boards.  How¬ 
ever,  administering  these  additional  tests  differs  from  the  above  test  procedure  only  in 
the  id  values  that  need  to  be  used  in  different  steps  for  the  board,  the  AG,  the  BIT 
modules,  and  in  setting  the  value  of  “muxctrl”  input. 
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Example  4 


Consider  a  board  aonsisrin^  of  three  amt)ii;uii;.y  groups  -'f  diips  anci  nsin'^  test 
point  monitoring  ^vith  ontpnc  data  '-onipression  :!S  the  BIT  rei-iiniqn'^.  Test  point  mon¬ 
itoring  is  assumed  to  be  performed  by  using  a  BILBO  modtile  used  as  a  paraiiei  signa¬ 
ture  analyzer,  while  test  vectors  at  the  AG-1  primary  inputs  are  provddeci  by  an  inter¬ 
nal  exclusive-or  LFSR  test  pattern  generator  .-is  shown  in  Figure  12.  For  details  on  the 
individual  BIT  modules  and  how  to  use  them  in  a  design,  the  reader  is  referred  to  the 
relevant  application  note.  Even  though  a  go/no-go  test  is  the  subject  of  this  example. 
Figure  12  also  shows  the  test  logic  incorporated  to  perform  fault-isolation  to  an  AG  for 
off-the-system  board  maintenance  purposes. 

It  is  assumed  that  the  BILBO  and  the  tpg  modules  have  internal  "enable’’  genera¬ 
tion  logic  shown  in  Figure  6,  and  the  AG  reset  and  preset  signals  in  Figure  6  can  be 
used  to  reset  and  preset  each  .\G  output  set  independently  of  another  AG  if  necessary. 
The  connections  indicated  in  Tables  1  and  4  are  assumed  to  have  been  made  befween 
each  of  the  BIT  modules  and  the  MN  I/O  at  the  MN-board  interface.  Four  MN  out¬ 
puts  that  are  not  assigned  to  the  BILBO  and  the  tpg  modules  need  to  be  assigned  to 
the  “muxctrl”  inputs,  and  an  arbitrary  choice  shown  in  Table  9  was  made. 


Table  9.  .\n  MN  Output/Multiplexer  Control  Signal 
Correspondence  for  the  Network  in  Figure  12 

MN  Output 

Signal 

CD|5! 

muxctrll 

CD  16] 

muxctrl2 

CD|7| 

muxctrlS 

CD[M] 

niuxctrld 

muxcrril 


Figure  12.  A  Board  Using  Test  Point  Monitoring  BIT 
Technique  with  Output  Response  Compression 
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The  AGs  are  assumed  to  be  synchronous  in  general,  even  though  portions  of  asyn¬ 
chronous  logic  can  also  be  handled.  The  system  clock  is  wired  such  that  when  "he 
"auxiliary  clock  enable”  line  is  activated,  it  is  disabled,  and  the  auxiliary  clock  controls 
the  board  operation.  It  is  further  assumed  that  whenever  the  auxiliary  system  clock  is 
held  at  low  level  and  the  AG  reset/preset  signals  are  not  active,  the  AGs  retain  their 
previous  state  indefinitely.  A  similar  assumption  holds  for  the  BIT  modules  on  the 
board  as  well.  Finally,  a  BIT  module-AG  assignment  shown  in  Table  10  is  assumed  for 
the  purpose  of  controlling  the  test. 


Table  10.  A  BIT  Module-AG  Assignment 
_ for  the  Network  in  Figure  12 _ 

BIT  Module  Assigned  AG 

tpg  AG-1 

BILBO  AG-3 


A  Procedure  for  Administering  Go/No-go  Test  of  the  Board  in  Example  4 

The  following  steps  are  generally  performed  by  the  system  level  TCU.  Steps  3  to 
8  accomplish  the  testing  of  the  BILBO  module,  while  steps  9  to  14  test  the  functions  of 
the  tpg  BIT  module.  Steps  15  to  17  set  up  the  board  for  a  go/no-go  test.  Test  vectors 
generated  by  the  tpg  module  are  applied  to  the  board  and  the  response  is  compressed 
by  the  BILBO  used  as  a  signature  analyzer  in  step  18.  Finally,  steps  19  and  20  facili¬ 
tate  comparison  of  the  final  signature  analyzer  stored  in  the  BILBO  with  the  expected 
one  and  determination  of  the  board  status. 
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1.  Activate  the  "auxiliary  clock  enable”  line,  and  hold  the  auxiliary  system  clock  and 
the  BIT  clock  lines  at  low  level  by  properly  gating  the  clock  signals  generated 
within  the  TCU. 

2.  Shift  in  a  24-bit  id  and  command  word  containing  the  appropriate  5-bit  subsys¬ 
tem  id,  6-bit  board  id,  3-bit  command  code  indicating  the  specific  MN  and  board 
reset,  and  2-bit  AG  reset/preset  code  corresponding  to  no  AG  reset  or  preset. 
This  word  has  to  be  shifted  in  through  ‘‘id_in”  input  under  the  control  of  GDI 
clock.  Arbitrary  values  may  be  used  for  the  5-bit  AG  id  and  the  3- bit  BIT  module 
id  for  this  step.  After  24  GDI  clock  cycles,  apply  the  load  address  bits  such  that 
only  the  “idjoad”  signal  is  nigh  for  one  GDI  clock  cycle.  This  step  ensures  that 
the  necessary  MN  and  board  reset  is  accomplished.  Raise  the  “dataout_load”  sig¬ 
nal  to  high  level,  which  configures  the  observation  register  in  the  MN  to  a 
parallel-latch  mode  of  operation  for  one  GDI  clock  cycle.  Then  serially  shift  out 
the  register  contents  (“dataout_load”  =  0)  and  verify  the  MN  and  board  reset 
bits  that  appear  on  the  “dataout”  line  at  the  MN-TGU  interface. 

3.  Repeat  step  2  with  another  24-bit  word  containing  the  3-bit  command  code  to 
deactivate  the  MN  and  board  reset  signals.  Also,  the  .5-bit  AG  id  corresponding 
to  AG-3  and  the  .3-bit  BIT  module  id  corresponding  to  the  BILBO  are  used.  This 
step  results  in  the  “enable”  of  the  BILBO  being  high,  which  in  turn  sets  it  up  to 
receive  control  signals  from  the  MN. 

4.  Shift  in  a  16-bit  control  and  data  word  through  “BIT  control  and  data”  input 
containing  all  zeros  except  “reset”  =  1  and  “resetl”  =  1.  After  16  GDI  clock 


Appendix  E-60 


:ycies.  raise  tlie  ■■.?oiuroi_ oau”  and  "dacainjoad''  signais  "o  hish  level  for  one 
CD[  clock  cycle.  This  sren  ensures  rhat  die  reset  if  ail  the  SIT  aioiiuies  oui  tiie 
board  is  accompiisheu. 

5.  Repeat  step  4  with  '‘shiften"  =  I  and  "c.j"  =  1  (ail  r,he  remaining  bits  oeing  zero). 
Then  apply  the  SIT  clock  for  one  clock  cycle.  This  step  enables  serial  shifting  of 
data  in  the  BILBO  module. 

3.  Apply  the  load  address  bits  so  that  ■■datain_load”  and  ■■dataoutjoad”  are  at  high 

level.  Shift  in  data  through  “BIT  control  and  data”  input  under  the  control  of 

CD!  clock,  .-kpply  the  BIT  clock  in  synchrony  with  the  GDI  clock.  The  output  bit 
stream  at  the  “dataout”  line  should  follow  the  input  bit  stream  with  a  known 
latency.  Hold  the  BIT  clock  at  low  level  at  the  end  of  this  step  by  properly  gating 
the  clock. 

7.  Repeat  step  4  with  ‘‘shiften’’  =  1,  “c,’’  =  1,  “c.,”  =  1,  and  "c.3'’  =  1  (all  the 

remaining  bits  being  zero).  Then  apply  the  BIT  clock  for  one  clock  cycle.  This 

step  enables  the  parallel  signature  analyzer  mode  of  the  BILBO. 

8.  Raise  the  “dataout_load’'  signal  to  high  lev^el.  Apply  the  BIT  clock  in  synchrony 
with  the  GDI  clock.  Linder  this  mode,  the  output  on  the  “dataout''  line  should 
match  the  precomputed  values  obtained  from  simulation  of  the  BILBO.  This  step 
generally  assumes  that  the  BILBO  has  a  non-zero  output  vector  at  Its  “out”  port 
at  the  end  of  step  6.  Hold  the  BIT  clock  at  low'  level  at  the  end  of  this  step  by 
properly  gating  the  clock  signal. 
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9.  Repeat  step  4.  This  step  resets  ail  the  BIT  moduies  on  the  boara  a'^ain. 

10.  Repeat  step  0  with  the  d-bit  AG  id  corresponding  "o  AG-i  and  "he  o-!)ir  BIT 
module  id  corresponding  to  rdie  r,pg  module. 

11.  Repeat  step  4  with  'Ahiften’’  =  1  (all  the  remaining  bits  being  zero).  Then  apply 
the  BIT  clock  for  one  clock  cycle.  This  step  enables  serial  shifting  of  data  in  the 
tpg  module. 

12.  Repeat  step  6.  This  step  checks  the  serial  shifting  function  of  the  tpg  module. 

13.  Repeat  step  4  with  "shiften'’  =  1.  '‘fbin”  =  1.  and  ‘‘fbctrl”  =  1  fail  the  remaining 
bits  being  zero).  Then  apply  the  BIT  clock  for  one  clock  cycle. 

14.  Repeat  step  8.  During  this  step,  the  output  on  the  "dataout"  line  should  match 
the  precomputed  values  obtained  from  simulation  of  the  test  pattern  generator 
module. 

15.  Shift  in  16-bit  control  and  data  words  containing  the  appropriate  control  and  data 
bits  required  for  initialization  of  the  tpg.  The  initialization  process  consists  of 
repeated  shifting  in  of  a  16-bit  control  and  data  word,  raising  the  '‘control_load’’ 
and/or  ‘‘datainjoad”  signals  to  high  level  for  one  GDI  clock  cycle  after  every  16 
GDI  clock  cycles,  and  applying  the  BIT  clock  for  one  clock  cycle.  During  this  ini¬ 
tialization  process,  the  16-bit  word  should  have  zeros  in  the  bits  corresponding  to 
the  multiplexer  control  signals. 

16.  Repeat  step  3  with  the  5-bit  .\G  id  corresponding  to  AG-3,  and  the  .3-bit  BIT 
module  id  corresponding  to  the  BILBO. 


Appendix  E-62 


17.  Repeat  step  7. 


18.  .\ppiy  the  au.xiliary  system  clock  and  the  BIT  clocks  in  synchrony  for  a  aiven 
number  of  clock  cycles.  During  this  step,  test  vectors  generated  by  the  tpg  are 
applied  to  AG-1  primary  inputs,  and  AG-3  primary  outputs  are  compressed  by 
the  BELBO  module.  Hold  the  auxiliary  system  clock  and  the  BIT  clock  at  low 
level  at  the  end  of  this  step  by  properly  gating  the  clock  signals. 

19.  Repeat  step  4  with  “reset  1”  =  1  (“reset”  =  0).  This  step  disables  shifting  in  the 
BILBO  and  thus  locks  the  resulting  signature  in  the  BILBO. 

20.  Raise  the  “dataout_load”  signal  to  high  level.  Repeat  step  5.  .A.pply  the  BIT 
clock  in  synchrony  with  the  GDI  clock.  Monitor  the  signature  stored  in  the 
BILBO  and  compare  it  with  the  expected  one. 

An  incorrect  signature  at  the  end  of  step  20  indicates  a  faulty  board,  while  a 
correct  signature  generally  implies  a  non-faulty  board.  However,  the  entire  procedure 
may  have  to  be  repeated  several  times  and  the  consistency  of  the  test  results  must  be 
verified  to  ensure  test  confidence.  Furthermore,  there  may  be  a  need  for  performing 
additional  tests  involving  multiple  boards  to  completely  check  the  interconnections 
between  the  board  under  test  and  the  other  boards.  However,  administering  these 
additional  tests  differs  from  the  above  test  procedure  only  in  the  id  values  that  need  to 
be  used  in  different  steps  for  the  board,  the  AG,  the  BIT  modules,  and  in  setting  the 
value  of  “muxctrll”  input. 
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Summary 


This  application  note  has  provided  a  fnnctionai  and  structitrai  iescriprion 
maintenance  node  iMN)  unit  and  illustrated  its  use  in  controlling  the  in-system  : 
test  by  considering  four  examples.  The  examples  chosen  encompass  all  the  board- 
BIT  techniques  supported  by  the  TEA  system. 
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SPECIFIC  B/IPLEMENTATION  OF  THE 


MAINTENANCE  NODE 


Objective 

This  note  provides  a  mixed-level  (i.e..  functional  block/gate /transistor  ievei) 
description  of  the  maintenance  node  unit  (MN)  that  has  been  simulated  and  verified 
for  its  intended  functionality  using  the  CADAT  simulator. 

The  “auxiliary  clock  processor”  in  the  MN  has  to  be  tuned  to  the  specific  applica¬ 
tion  under  consideration  so  that  it  generates  the  required  clock  phases,  satisfying  the 
desired  phase  and  frequency  relationships.  It  is  assumed  in  this  application  note  that 
the  auxiliary  clock  processor  is  a  non-overlapping  two-phase  clock  generator. 
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Block  Diagram 


Board 


Figure  1.  Block  Diagram  of  the  MN  Showing  Its  I/O  Pins 
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Pin  Description  (See  also  the  logic  diagrams  and  the  application  note  on  the 
utilization  of  the  MN) 


Name 

Description 

Auxiliary  system  clock  enable 

aux_;'i  tii 

Auxiliary  system  clock 

aux_phil,  aux_phi2 

Non-overlapping  phases  of  the  auxiliary  system  clock 

bidf5:0l 

d-bic  board  identification  code  fuli  igeneraiiy  hardwiredl 

breset 

Board-reset  output  from  the  \IN 

odi_phi 

Control,  data,  and  id  (CDI)  clock 

cdi_phil.  cdi_phi2 

Non-overlapping  phases  of  the  CDI  clock 

cd_in 

Serial  control  and  data  input 

cd[l6:l| 

Parallel  control  and  data  outputs 

comp 

"Compare  successful*’  signal  pin 

dout 

Serial  data  output  from  the  \IN 

id_in 

Serial  identification  address  input 

id_load 

The  "identification-load”  signal  pin 

laddri2:0] 

"Load  address  <lecoder”  inputs 

obr[3:l],  usd[2:lj 

"Observation  register*’  inputs 

reset 

"Power-on  reset*’  input  for  the  MN 

ss[4:0j 

5-bit  subsystem  id  ^generally  hardwired) 

tphi 

BIT  module  clock 

tphil.  tphi2 

Non-overlapping  phases  of  the  BIT  module  clock 
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Logic  Description 


riie  -VIN  has  hie  t'ollowin'i  fimcrhonai  croups; 
I')  Concroi  and  <iaca  register 


2)  Identification  and  command  register.  a.nd  the  associated  logic 

3)  Observation  register 

4)  Load  address  decoder 

5)  Auxiliary  system  clock  processor 

6)  Control,  data,  and  id  (CDI)  clock  processor 

7)  BIT  module  clock  processor 


Mixed-level  (l.e.,  functional  bicck/gate/transistor  level)  descriptions  of  these  consti¬ 
tuent  groups  are  provided  in  the  following  paragraphs. 

1)  Control  and  data  register 

Figure  2  shows  the  control  and  data  register  portion  of  the  MN.  Its  C.ADAT 
description  uses  the  primitives  “dff-l,”  ‘‘nlmos,’’  “buf,”  and  gates  such  a-s  "and'' 
and  '‘inv.'’ 

2)  Identification  and  command  register,  and  the  associated  logic 

Figure  3  illustrates  the  functions  of  the  id  and  command  register  portion  of  the 
MN.  Its  CADAT  description  uses  the  primitives  “dff-l,”  “nlmos,”  “buf,”  "com¬ 
parator,”  “decbin”  (decoder),  and  other  basic  gates. 
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Figure  2.  Control  and  Data  Register  Portion  of  the  MN 


Figure  3.  Identification  and  Command  Register  Portion  of  tlie  MN 


3)  Observation  register 


The  observafaon  register  portion  of  the  MN  is  shown  iu  figure  4.  Its  C-VDAT 
description  uses  the  primitives  ‘‘dff-1.”  '‘mux/’  and  "huf.” 


4)  Load  address  decoder 

Figure  5  shows  an  implementation  of  the  load  address  decoder.  Its  CADAT 
description  uses  the  basic  gates  and  the  primitive  “buf."’ 

o)  Auxiliary  system  clock  processor 

A  non-overlapping  two-phase  clock  generator  shown  in  figure  6  is  assumed  to  be 
the  auxiliary  system  clock  processor  in  the  chosen  specific  implementation.  Its 
CADAT  description  uses  a  “3s-h”  (tristate  buffer)  primitive  in  addition  to  the 
basic  gates. 

6  &  7)  GDI  and  BIT  module  clock  processors 

These  are  the  same  as  in  figure  6,  except  no  output  tristate  buffers  are  needed. 
However,  their  CADAT  description  utilizes  the  tristate  buffers  with  their  control 
input  tied  to  power  supply  (Vdd)  for  reasons  of  uniformity. 
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Observation  Register  Portion  of  the  MN 


laddr[Oj  ladd 


r[l! 


laddr 


(o! 

t-i 


Figure  5.  Load  Address  Decoder 
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MN  reset 

!  aux  ^naoie 


tristate  buiTer 


Figure  6.  Twophase  Clock  Generator  Used  as  Auxiliary  System  Clock  Processoi 
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PROGR.\MM.\BLE  FEEDBACK  PSEUDORANDOM  TEST  PATTERN 


GENERATOR  (EXTERNAL  SXCLUSIVE-OR  IMPLEMENTATION) 

.APPLICATION  NOTE 


Objective 


The  objective  of  this  application  note  is  to  describe  the  functionaiicy  of  the  pro¬ 
grammable  feedback  pseudorandom  test  pattern  generator  module  using  an  external 
exc!usive-or  feedback  structure. 


Block  Diagram 
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Figure  1.  Block  Diagram  of  a  Pseudorandom  Test  Pattern  Generator  Module. 
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Pin  Description  'see  also  the  logic  diagram  and  module  functions) 


Name 


••eser 


Description 

X'iasrer  i-esei;  of  ail  die  fliD-fioDs 


tDhii/r,Dhi2  Two-oaase  oiocic 


inaoiel 


Shift  enable  I  for  the  eontroi  inouts 


bCtrl 


cascade 


!fin 


fbin 

fbctrl 

sdata 

shift  en 

Ifbclose 

out  [I6:l] 

fbout 

fboutl 

Ifout 

Ifoutl 

tout 


Tristace  control  for  ''toiio”  output 

Enable  eontroi  for  the  serial  data  (used  in  cascading  muitipie  test  pattern 
generator  modules) 

Data  input  used  in  cascading  muitipie  test  pattern  generator  modules 

Input  of  the  feedback  network  (used  in  cascading  muitipie  test  pattern 
generator  modules; 

Feedback  coefficient  input 

Control  input  to  enablel  feedback  connection 

Serial  data  input 

Shift  enablel  for  the  data  in  the  test  pattern  generator 

Input  pin  used  in  cascading  multiple  test  pattern  generator  modules 

Data  outputs  of  the  test  pattern  generator 

Feedback  coefficient  output 

Feedback  coefficient  output  for  test  control  purposes 

Output  of  the  feedback  network  (used  in  cascading  multiple  test  pattern 
generator  modules) 

Output  of  the  feedback  network  for  test  control  purposes 
Serial  test  data  output 
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Module  Function 


The  primary  function  of  this  module  is  to  generate  pseudorandom  test  vectors  for 
application  to  a  unit  under  test  (UUT).  Ail  the  required  control  circuitry  is  incor¬ 
porated  within  the  module  itself  so  that  the  master  test  oontroi  unit  TTCU)  can  prop¬ 
erly  control  the  operation  of  multiple  test  pattern  generators  in  a  design  with  minimal 
need  for  additional  “glue”  logic. 

Required  Pin  Connections 

Certain  pin  connections  are  necessary  to  use  the  test  pattern  generator  module.  If 
the  module  is  to  be  used  by  itself  (i.e.,  as  a  16-bit  test  vector  generator),  the  connec¬ 
tions  shown  in  Figure  3  are  required. 


Ifout 


Ifb  close 


Test  Pattern 
Generator 


Ifin 


(0) 


Xi 

C 

CO 


k 

cd 

o 


(1)  (0) 


Figure  3.  Required  Pin  Connections  to  Use  a  Single  Test  Pattern 

Generator  Module 


Appendix  E-78 


[f  multiple  test  pattern  generator  modules  are  to  be  used  as  a  single  programm¬ 
able  feedback  test  pattern  generator,  the  connections  shown  in  Figure  4  (illus¬ 
trated  for  three  modules)  are  required.  The  terms  ’‘enabiel,"  ‘‘fbctrl.’'  “sdata,"  and 
■‘shiften’’  are  common  to  all  the  test  pattern  generator  modules  in  this  mode  of  opera¬ 
tion. 


Figure  4.  Required  Pin  Connections  to  Use  Multiple  Test  Pattern 
Modules  as  an  Equivalent  Single  Module 


Propagation  delay  associated  with  the  exclusive-or  gate  chain  in  the  feedback 
path  is  of  genuine  concern  when  using  multiple  test  pattern  generator  modules  (as 
shown  in  Figure  4)  as  it  has  an  adverse  impact  on  the  maximum  test  clock  frequency. 
In  certain  applications,  an  internal  exclusive-or  implementation  of  the  test  pattern  gen¬ 
erator,  which  is  described  in  a  different  application  note,  might  be  advantageous  to  use 
since  the  feedback  path  in  an  internal  exclusive-or  implementation  does  not  involve 
gate  delays.  It  should  be  noted,  however,  that  the  maximum  allowed  test  clock  fre- 
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ajiency  always  reduces  albeit,  by  different  extents)  as  a  result  of  cascading  the  test 
pattern  generator  -uouiues.  irrespective  of  the  implementation  used.  Hence,  in  terms 
of  speed,  the  i)est  possible  hardware  implementation  of  the  test  pattern  generator 
module  is  a  fixed  word-length  module  with  no  provisions  for  cascading.  However,  .such 
a  design  reduces  the  flexibility  in  utilizing  the  module  and  must  be  carefully  con¬ 
sidered. 

Operation  of  the  Module 

•A-ll  the  test  pattern  generator  modules  in  the  design  are  reset  by  a  master  “reset" 
signal  common  to  all  the  modules.  Then,  each  module  is  selected  by  means  of  its 
enablel  signal.  Predetermined  test  patterns  are  shifted  through  the  feedback  coeffi¬ 
cient  and  data  shift  registers  through  “fbln"  and  “sdata"  inputs  respectively.  The 
outputs  at  “fbout,"  “Ifout,"  and  “tout”  pins  are  verified  by  the  test  control  unit 
(TCU)  against  the  unexpected  values.  These  tests  are  performed  for  “shiften"  =  1 
and  “fbctrl”  =  0;  “shiften”  =  1  and  “fbctrl”  =  1;  and  “shiften”  =0  control  signal 
values.  If  any  of  these  tests  fail,  the  test  pattern  generator  module  could  be  faulty  and 
might  have  to  be  replaced.  Upon  completion  of  these  tests,  the  coefficients  (binary  1 
and  0)  corresponding  to  the  desired  feedback  polynomial  are  shifted  in  through  ‘‘fbin" 
input  and.  simultaneously,  test  pattern  generator  data  outputs  are  initialized  to  a 
given  not-all-zero  state  by  shifting  data  through  “sdata”  input.  During  this  initializa¬ 
tion  period,  “shiften”  =  1  and  “fbctrl”  =  0  logic  values  are  maintained.  After  a 
predetermined  number  of  clock  cycles,  “fbctrl”  is  raised  high  and  then  “enablel”  is 
brought  low  in  the  succeeding  clock  cycle  so  that  the  feedback  coefficients  and  the 
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control  signals  are  latched.  From  this  point  on.  oseuaoranciom  'est  vectors  tre  o.'a 


able  at  "oiit  :16:ii"  outputs  every  'UCiU';  :ycie.  File  rspention  '.nrer''-; 
test  patterns  is  dependent  on  the  feedback  polynomial  'nosen.  anc 
tion  interval  of  2"^’  —  I  Is  obtained  by  choosing  a  primitiv^e  feedbrncK 


a  niaoiniai 
poivnmiiiai  io 


Fisbi  msb  1 

typical  timing  sequence  to  shift  in  a  feedback  polynomial  oOOdOO  10000 10001 

i'lsbj  msi 

shown  in  Figure  o.  The  test  pattern  generator  is  initialized  to  qoqqqq^qqOOIOOOL 
.AJ'ter  seventeen  clock  cycles,  the  test  pattern  generator  is  avaiiabie  for  use. 
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Figui-e  f).  r.iniiig  Diagrnm  for  Llic  Oiuiralioii  of  tin:  'I’csl,  PaK.crn  i  .'eiicratui  Mo,|iiK: 


Use  of  the  Test  Pattern  Generator  Moduie  In  a  Design 

Independenc  of  rue  BIT  "eeiiniaue  used  ;u  riie  iesigii.  tiie  "et-t  ontTeru  ^eiieraror 
aioduie  ran  be  used  :o  provide  pseudorandom  ’.npucs  :o  a  unir,  under  rest  T.T.  Tb  Note 
that  the  LIJT  can  be  one  or  muitipie  ambiguity  groups  ^  AGs).  iepending  on  the  BIT 
technique  used.  The  applicability  of  pseudorandom  patterns  in  testing  the  I.T'T  must 
be  verified  before  actually  using  the  test  pattern  generator  moduie.  Figure  6  shows  a 
typical  application  of  the  test  pattern  generator  moduie. 

normal  mode 
^  inputs 


Figure  6.  A  Typical  Application  of  the  Test  Pattern  Generator  Module 
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In  appllcacions  -.vaere  only  .serial  inpuis  are  available  for  shiitins  in  test  vectors. 


he  conii'zuraciou  in  Flynre  7  can  iie  nsed. 


TPG 


normal  mode 
serial  inputs 


muxctrl 


i 


Figure  7.  Another  Typical  Application  of  the  Test  Pattern  Generator  Module 
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PROGRAMMABLE  FEEDBACK  PSEUDORANDOM  TEST  PATTERN 
GENERATOR  (INTERNAL  EXCLUSIVE-OR  IMPLEMENTATION) 

APPLICATION  NOTE 

Objective 

The  purpose  of  this  application  note  is  to  describe  the  functionality  of  the  pro¬ 
grammable  feedback  pseudorandom  test  pattern  generator  module  using  an  internal 
exclusive-or  feedback  structure. 

Block  Diagram 


out[l]  out(2]  outfiej  fbout  fboutl  tout 


Figure  1.  Block  Diagram  of  a  Pseudorandom  Test  Pattern  Generator  Module 
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Pin  Description  (see  also  the  logic  diagram  and  module  functions) 


Name 

reset 

tphil/tphi2 

enablel 

tctrl 

senab 

cascade 

fbin 

fbctrl 

sdata 

shiften 

Ifbclose 

out  [16:1] 

fbout 

fboutl 

tout 


Description 

Master  reset  of  all  the  flipflops 
Two-phase  clock 

Shift  enablel  for  the  control  inputs 
Tristate  control  for  “tout”  output 

Enable  control  for  the  serial  data  (used  in  cascading  multiple 
test  pattern  generator  modules) 

Data  input  used  in  cascading  multiple  test  pattern  generator  modules 

Feedback  coefficient  input 

Control  input  to  enablel  feedback  connection 

Serial  data  input 

Shift  enablel  for  the  data  in  the  test  pattern  generator 

Input  pin  used  in  cascading  multiple  test  pattern  generator  modifies 

Data  outputs  of  the  test  pattern  generator 

Feedback  coefficient  output 

Feedback  coefficient  output  for  test  control  purposes 
Serial  test  data  output 
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Module  F unction 


The  primary  function  of  this  module  is  to  generate  pseudorandom  test  vectors  for 
application  to  a  unit  under  test  [UUT).  All  the  required  control  circuitry  is  incor¬ 
porated  within  the  module  itself,  so  that  the  master  test  control  unit  (TCU)  can  prop¬ 
erly  control  the  operation  of  multiple  test  pattern  generators  in  a  design  with  minimal 
need  for  additional  "glue”  logic. 

Required  Pin  Connections 

Certain  pin  connections  are  necessary  to  use  the  test  pattern  generator  module.  If 
the  module  is  to  be  used  by  itself,  i.e.,  as  a  16-bit  test  vector  generator,  the  connec¬ 
tions  shown  in  Figure  3  are  required. 


(1)  (0) 


Figure  3.  Required  Pin  Connections  to  Use  a  Single  Test  Pattern  Generator  Module 
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If  multiple  test  pattern  generator  modules  are  co  be  used  as  a  single  programm¬ 
able  feedback  test  pattern  generator,  rlie  ■:onnecrions  shown  ‘n  Figure  t  iilus- 
trated  for  three  modules]  are  required. 


Figure  4.  Required  Pin  Connections  to  Use  Multiple  Test  Pattern 
Modules  as  an  Equivalent  Single  Module 

The  terms  “enable,”  “fbctrl,”  “sdata,”  and  “shiften”  are  common  to  all  the  test  pat¬ 
tern  generator  modules  in  this  mode  of  operation. 

Unlike  the  feedback  path  in  the  external  exclusive-or  implementation  (which  is 
described  in  a  separate  application  note),  the  feedback  path  in  this  implementation 
does  not  involve  gate  delays.  Hence,  a  potentially  higher  speed  of  operation  (higher 
test  clock  frequency)  is  possible  provided  the  driver  associated  with  the  most  signifi¬ 
cant  bit  of  the  test  pattern  generator  is  designed  properly.  However,  when  multiple 
test  pattern  generator  modules  are  cascaded  as  in  Figure  4,  speed  of  operation  will  be 
affected  to  a  certain  extent  because  of  higher  loading  on  the  “out  [16]”  node 
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corresponding  to  the  most  significant  bit  of  the  test  pattern  generator  .■■oiuilhi”  node 
of  ^3  in  Figure  41. 

Operation  of  the  Module 


Ail  the  test  pattern  generator  modules  in  the  design  are  reset  :}y  a  master  ’reset  " 
signal  common  to  all  the  modules.  Then,  each  mo'luie  is  selected  by  means  of  ‘ts 
“enablel”  signal.  Predetermined  test  patterns  are  shifted  through  the  feedback;  coeffi¬ 
cient  and  data  shift  registers  through  ’Tbin’'  and  ’’sdata"'  inputs  respectively.  The 
outputs  at  “fboutl"  and  "tout”  pins  are  verified  against  the  expected  vmlues.  These 
tests  are  performed  for  “shiften”=  1  and  ■‘fbctrl”=  0.  ■fshiften'’=  1  and  ■d’bctri”=  1. 
and  ‘‘shiften”=  0  control  signal  values.  If  any  of  these  tests  fail,  the  test  pattern  gen¬ 


erator  module  could  be  faulty  and  might  have  to  be  replaced. 


Then,  the  coefficients  (binary  1  and  0)  corresponding  to  the  desired  feedback 
polynomial  are  shifted  in  through  "fbin”  input,  and,  simultaneously,  test  pattern  gen¬ 
erator  data  outputs  are  initialized  to  a  given  not-all-zero  state  by  shifting  data 
through  "sdata”  input.  During  this  initialization  period,  "shiften'’=  1  and  ■■fbctrr'=  0 
logic  values  are  maintained.  ,After  a  predetermined  number  of  clock  cycles.  ’Tbctrl”  is 
raised  high  and  then  "enablel”  is  brought  low  in  the  succeeding  clock  cycle  so  that  the 
feedback  coefficients  and  the  control  signals  are  latched.  From  this  point  on.  pseu¬ 
dorandom  test  vectors  are  available  at  "out[l6:l]”  outputs  every  clock  cycle.  The 
repetition  Interval  of  the  generated  test  patterns  is  dependent  on  the  feedback  polyno¬ 
mial  chosen,  and  a  maximal  repetition  interval  of  2^*^  -  1  is  obtained  by  choosing  a 
primitive  feedback  polynomial  [l].  A  typical  timing  sequence  to  shift  in  a  feedback 


Appendix  E-90 


Doivnomial.*  '  OOOOOIOOOOIOOO'-'^!’'^ '3  siiown  ia  Figure  5.  The  tesr  oattern  zenera 


^or  is  initialized  "o  Alter  severueen  ’iotez 


Tries,  "he 


pacterii  generator  is  avaiiMine  tor  ^ise. 
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tphil 
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Figure  5.  Timing  Diagram  for  the  Operation  of  the  Test  Pattern  Generator  Module 


Use  of  the  Test  Pattern  Generator  Module  in  a  Design 


Please  see  the  corresponding  subsection  in  the  application  aom  m  ■p'-cgi’amniai'h 
Feedback  Pseudorandom  Test  Pattern  Generator  :Exr.ernal  Ex'dnsice-or  imoiemenra 
tion).” 
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SCAN-SET  BIT  MODULE 

.application  note 


Objective 

The  objective  of  this  application  note  is  to  describe  the  functicnaiity  of  the  scan 
set  BIT  module,  and  to  show  how  it  is  inserted  in  a  design  in  order  to  facilitate  test. 

Block  Diagram 


Scan-Set  BIT  Module 


Figure  1.  A  Block  Diagram  of  the  Scan-set  BIT  Module 
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Pin  Description  (see  also  the  logic  diagram  and  module  functions) 


Name 


Cl,  C. 
enbie 

i-ctrl,  tctrll 


Description 

Mode  :onci-oi  inputs 

Shift  enable  for  '‘ontroi  and  data  inputs 

Tristate  controls  for  '‘scanout"  and  “scanoutr' 
outputs 


inh 

tphil,tphi2 
scanin.  scaninl 
out[l6:l] 

in[l6:l] 

uutin[l6:l] 

scanout,  scanoutl 
reset 


Inhibit  signal  that  carises  the  outputs  uutinil6:lj 
to  be  0  when  active  (1) 

Two-phase  clock 

Serial  data  inputs 

16  parallel  input  pins  that  will  be  connected  to  the 
outputs  of  the  ambiguity  group  (AG)  under  test 

16  parallel  input  pins  that  will  be  connected  to  the 
outputs  of  an  AG  corresponding  to  normal  mode  of  operation 

16  parallel  output  pins  that  will  be  connected 
to  the  inputs  of  the  AG  under  test 

Serial  data  outputs 

Master  reset  of  all  the  flip-flops 
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Logic  Description 


scanoutl 


'pnu-nanie 


uiitin|16{ 


uutin|lS{ 


uulin|l| 


Figure  2.  Logic  Diagram  of  the  Scan-set  BIT  module 
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Module  Functions 


enble 

Cl 

C.; 

inn 

rctrl 

rctrll 

1 

1 

0/1 

0/T 

0/1 

0/1 

Parallel  cransfer  jf "o  ‘./S  .iiM 
uucinil6:l!  ro  O's 

1 

0 

0/1 

0/1 

0/T 

0/T 

Serial  shiiting-di  of  iaia  from  ■scauiu  ' 
and  '‘scaninl  ’ 

1 

0/1 

1 

0 

0/1 

0/T 

Q  outputs  are  connectea  "o  uutini  16:11 

1 

0/1 

0/1 

1 

0/1 

0/1 

uutinll6:ij  =  0 

1 

0/1 

0 

0 

0/1 

0/1 

in[l6:l]  connected  to  uutinil6:l' 

0/1 

0/1 

0/1 

0/1 

0 

0/1 

Scanout  =  Z  /high  impedance) 

0/1 

0/1 

0/1 

0/1 

1 

0/1 

Scanout  =  Qis 

0/1 

0/1 

0/1 

0/1 

0/T 

0 

Scanoutl  =  Z  (high  impedance) 

0/1 

0/1 

0/1 

0/1 

0/1 

1 

Scanoutl  =  Q'jg 

enable 

=  0 

latches  the  control  inputs  Ci 
shift  registers. 

and  Co  and  disables  shifting  of  data  in  the 

Incorporation  of  the  BIT  Modules  into  Design 

A  hardware  design  will  be  partitioned  into  Ambiguity  Groups  (AGs)  of  intercon¬ 
nected  chips  before  the  BIT  modules  are  inserted  in  the  design.  Insertion  of  the  scan- 
set  BIT  modules  is  illustrated  using  the  example  in  Figure  3. 


Appendix  E-97 


Before  BIT  Insertion 


Inputs  ro  AG-l 


.nouts  ro  AG-'2 


.^fter  BIT  Insertion 


scaQOUl  jcanoutl  ^canout  canouil 


scaoin  enable  scaainl  icanio  enable  &caninl 


Figure  3.  An  Example  Showing  the  Insertion  of  the  Scan-set  BIT  Modules 
in  a  Design 


As  evident  from  the  figures,  all  inputs  to  an  AG  pass  through  the  BIT  module(s) 
associated  with  that  AG,  and  all  the  AG  outputs  will  be  connected  to  the  ‘‘out'’ 
port(s)  of  the  associated  BIT  module(s). 
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Another  exampie  iilustratins  'he  insertion  ot‘  'he  scan-set  BIT  modules  is  shown  in 
Figure  4. 


Beibre 

BIT  Insertion 


i 

AG- 1 

AG- 2 

t 

AG-3  i — 

1 

j  1 

!  i 

j 

i 

After 

BIT  Insertion 


Figure  4.  Another  Example  Illustrating  the  Insertion  of  the  Scan-set  BIT 
Modules  in  a  Design 


A  master  Test  Control  Unit  (TCU)  is  assumed  to  be  incorporated  into  the  design 
in  order  to  perform  the  following  functions: 


1.  Checking  the  functionality  of  the  BIT  modules; 

2.  Providing  either  deterministic  or  pseudorandom  test  patterns  to  the  AG  under 
test  by  shifting  in  data  through  “scanin”  inputs  of  the  associated  scan-set  BIT 
modules; 
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3.  Collecting  test  cesnoiise  lata  :  hrougn  "scanout”  outputs  of  the  BIT  modules,  and 
perfcrming  die  -lecsssar-  iaca  a.'inpression  and/or  comparison  a-ita  the  e>;pecced 
responses; 


4. 


Providing  ail  rae  aecessarp  c-ourrni  -ignais.  such  as  "CT. 
the  BIT  aiodiiie.s: 


"C.t”.  and  "enable",  for 


o.  Exercising  control  over  Tie  AG  clocks  iphil/phi2  assumed)  and  tdie  BIT  module 
clocks  tphii/tphi2. 


Before  discussing  a  step-oy-step  procedure  for  testing  the  AGs,  the  following 

issues  are  to  be  considered: 

1.  It  may  be  preferable  to  treat  the  control  inputs  of  an  AG  differently  from  its  data 
inputs,  and  to  use  different  scan-set  modules  in  conjunction  with  control  and  data 
inputs,  as  shown  in  Figure  o. 

This  feature  facilitates  the  application  of  deterministic  test  patterns  at  the  control 
inputs  of  an  AG  while  allowing  pseudorandom  patterns  to  be  applied  at  its  data 
inputs.  Even  though  the  logic  diagram  shown  for  the  scan-set  BIT  module 
assumes  a  word  size  of  16  bits,  in  practice,  modules  with  smaller  word  sizes  (4  bits, 
8  bits,  etc.)  may  also  be  utilized  in  the  designs  in  order  to  reduce  the  unused  pins 
of  the  BIT  module. 
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Control 


Before 

BIT  Insertion 


Inputs 

Data 

Inputs 


AG 


Outputs 

- ^ 


After 

BIT  Insertion 


Figure  5.  An  Example  Illustrating  the  Use  of  Different  BIT  Modules 
for  Control  and  Data  Inputs  of  an  AG 

It  is  also  conceivable  to  pass  only  the  data  inputs  of  an  AG  through  a  scan-set 
BIT  module  while  allowing  the  control  inputs  to  be  directly  connected  to  the  AG, 
as  shown  in  Figure  6. 
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AG 


Control 

Inputs 

(from  another 
AG) 


! 


BIT-1  i  !  1 

Data 

"in* 

.  .1  ! 

Inputs 

I  ■ 

■out"  1 

t 

1 

Figure  6.  An  Example  in  which  a  BIT  Module  is  L'sed  only 
for  the  Data  Inputs  of  an  AG 

In  such  a  scheme,  it  is  generally  assumed  that  the  AGs  that  generate  the  control 
inputs  are  tested  first,  and  their  outputs  are  set  to  the  desired  values  during  the 
testing  of  other  AGs.  The  feasibility  of  properly  implementing  this  scheme 
depends  on  several  factors,  such  as  the  design  of  the  AGs  in  the  system,  required 
fault  isolation  resolution,  etc.,  and  it  is  not  considered  in  the  step-by-step  pro¬ 
cedure  given  later. 

If  the  number  of  inputs  or  outputs  of  an  AG  exceed  the  default  word  size  of  the 
BIT  module,  multiple  modules  need  to  be  used.  One  way  of  interconnecting  mul¬ 
tiple  scan-set  BIT  modules  is  shown  in  Figure  7. 
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icanoufl 
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BIT-2 
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t  t 


inh 


BIT-1 


“TT" 

scanm  scaninl 
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I 


tctrl=  r  tctril='r 


Figure  7.  L’se  of  Multiple  Scan-set  BIT  Modules 


In  this  example,  “scanout"  and  '‘scanoutl’’  of  BlT-1  are  connected  to  “scanin" 
and  “scaninl’’,  respectively.  Furthermore,  “tetri”  and  “tctrll”  of  BIT-1  are  tied 
to  ‘1’.  “C,”,  “Cj”,  “inh”,  and  “enable”  are  common  to  both  modules.  (“Reset”, 
“tphil”,  and  “tphi2”  are  always  common  to  all  scan-set  BIT  modules.) 


A  Procedure  for  Testing  of  AGs 
Preliminary  Steps 


1.  Reset  all  the  BIT  modules  in  the  design  by  applying  a  master  “reset”  signal. 


Bring  all  the  AGs  into  predetermined  and  well-defined  states  by  means  of  global 
control  signals  such  as  “reset”  and  “preset’’,  and  then  disable  the  clocks  of  the 
AGs  (phil/phi2  clocks  assumed)  from  further  altering  their  state. 
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■■“nabie”  signal,  shift  in  predetermined 
:broiig;i  '-canin  "  and  ■’scaninr'  inputs 
and  verify  rhe  outpur  data  at  "scanout" 
in  the  scanii'-d-our  lata,  the  BIT  module 
replaced. 


-4.  Change  the  -rmtroi  at  (ih  ..C,=  l)  and  perform  the  parallel  transfer  of  data  from 
■‘outilb:!;"  to  Qs.  then  set  C.=0  again  and  verify  the  stored  data  by  serially  shift¬ 
ing  it  through  ‘scanout  In  this  context,  both  reset  and  preset  capabilities  of  an 
AG  may  be  reuuired  so  that  ‘‘outiTb:!]”  pins  can  assume  both  logic  T’  and  ‘O’. 
Similarly,  perform  ‘he  parade;  transfer  of  data  from  “ln[l6:l]"  to  Q's  by  setting 
C,  =  l  and  Ci^O.  and  verify  the  stored  data  by  serially  shifting  it  out  through 
"scanoutl"  (Ci=0).  If  the  scanned-out  data  is  erroneous,  fault  isolation  can  be 
achieved  to  the  combination  of  an  AG.  a  set  of  a.ssociated  scan-set  BIT  modules, 
and  the  inherent  interconnections,  under  the  assumption  that  any.  but  only  one. 
.■\G  can  be  faulty  during  testing. 


AG  Testing 

5.  Shift  in  a  predetermined  control  data  pattern  into  the  BIT  module  associated 
with  the  control  inputs  of  the  .\G  under  test:  then,  by  disabling  further  shifting, 
the  .A.G  is  set  up  for  test  under  a  known  control  mode. 


6.  Shift  in  a  test  data  pattern  through  “scanin”  of  the  BIT  module  associated  with 
the  data  inputs  of  the  AG  (Ci=0,  €0=1).  .After  a  predetermined  number  of 
tphil/tphi2  clock  cycles,  the  data  pattern  is  ready  for  parallel  transfer  to  the  .AG 
under  test.  Then,  enable  the  .AG  clocks  (phil/phi2)  for  one  clock  cycle  and  dis¬ 
able  them  again. 


7.  If  the  AG  outputs  are  to  be  verified  at  this  time,  set  the  control  signal  Cj  (Ci=l) 
and  perform  parallel  transfer  of  ‘‘outllG:!]”  to  Qs.  Set  Ci=0  and  shift  out  the 
stored  data  through  ‘‘scanout’’,  then  verify  the  output  data  against  the  expected 
response  data.  If  the  .AG  outputs  need  not  be  verified  at  this  time,  then  skip  this 
step. 


8.  Repeat  steps  6  and  7  a.s  many  times  as  needed  (determined  from  a  priori  simula¬ 
tions  of  the  .AG). 
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9.  Repeat  steps  o  through  S  as  many  dmps  -is  neeae-i  'or  litfprenr.  -onri-oi 

modes  of  the  AG). 

The  above  AG  testing  procedure  v/lii  'oe  inpiipfi  sequentially  "o  ;ul  "he  AGs.  he., 
the  AGs  will  be  tested  one  after  another  using  scens  •'»  ^hrcngii  '■).  If  "esr  of  an  AG  faiis 
(i.e.,  incorrect  response)  fault  isolation  is  to  the  combination  of  rhe  AG.  the  BIT 
module(s)  associated  with  its  I/O.  and  the  inherent  interconnections,  unaer  the 
assumption  that  any.  but  only  one,  AG  can  be  fault .  during  •  esting. 

Timing  Consideratons 

The  mode  control  signals  (Cj  and  Co)  have  to  be  valid  one  clock  cycle  before  the 
actual  data.  For  instance,  parallel  transfer  of  “in[l6:l]”  to  Q'  outputs  and  serial 
shifting-out  of  that  data  through  “scanoutT’  involves  the  timing  sef|ue!ue  shown  in 
Figure  8. 
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“^he  daca  t;hrough  ■'soanour/'  oucpur. 
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TESTING-SWITCH 


.\PPLICATION  NOTE 


Objective 

The  objective  ot'  this  ap plication  note  is  to  describe  the  functionality  of 
testing-switch  module  and  to  show  how  it  is  used  in  a  design  to  facilitate  test. 

Block  Diagram 
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TESTING-SWITCH 
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Figure  1.  Block  Diagram  of  the  Testing-switch  Module 
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Pin  Description  (see  also  the  Logic  Diagrams  and  Module  Funccions; 


Name 

Description 

reset 

Reset  input  of  all  the  flip-flops  excluding  "he  ones 
corresponding  to  "‘sashiften”  and  "enabin”  'nputs 

reset 1 

Reset  input  of  the  flip-flop  corresponding  'o  r.he 
“sashiften”  input 

reset2 

Reset  input  of  the  flip-flop  corresponding  to  the 
“enabin”  input 

tphil/tphi2 

Two-phase  clock 

clkl/clk2 

Two-phase  clock  for  the  flip-flop  corresponding 
to  the  “enabin”  input 

enabln 

Shift  enable  for  control  inputs 

fbcoefin 

Feedback  coefficient  input  of  the  test  pattern 
generator  associated  with  the  testing-s-witch 

genctrlin 

Control  input  to  enable  feedback  connection  in  the 
test  pattern  generator  associated  with  the  testing-switch 

gendatain 

Serial  data  input  of  the  test  pattern  generator 
associated  with  the  testing-switch 

genshiften 

Shift  enable  for  the  data  in  the  test  pattern 
generator  associated  with  the  testing-switch 

saclin,sac2m 

Mode  control  inputs  of  the  signature  analyzer 
associated  with  the  testing-switch 

sashiften 

Shift  enable  for  the  data  in  the  signature  analyzer 
associated  with  the  testing-switch 

sasin 

Serial  data  input  of  the  signature  analyzer  associated 
with  the  testing-switch 

satctrlin 

Tristate  control  for  “satout”  output 
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ctrllin,ctrlOin  Mode  control  Inputs  ot  the  testing-switch 


dinil6:lj  Parallel  data  inputs  of  the  tescing-'witch 

enabout  Output  of  the  flip-flop  corresDonaing  'o  t. tie  ■-^uabin  ’ 

Input 

satout  Serial  test  data  output  of  the  signature  analyzer 

associated  with  the  testing-switch 

dout[l6:l]  Parallel  data  outputs  of  the  testing-switch 

Logic  Diagrams 

Figure  2  shows  an  overall  description  of  the  testing-switch  module,  vvhile  Figure  3 
illustrates  the  logic  of  the  test  pattern  generator  associated  with  the  testing-switch. 
Figure  4  shows  the  logic  of  the  signature  analyzer  associated  with  the  testing-switch. 
Finally,  Figure  5  illustrates  the  control  of  the  data  exchange  network. 
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•ini 


-  dlO 


Figure  5.  Control  of  the  Data  Exchange  Network 

Module  Functions 

The  testing-switch  module  mainly  performs  three  functions:  it  provides  pseudo¬ 
random  test  patterns  to  an  ambiguity  group  (AG)  (i.e.,  smallest  group  of  chips  to 
which  a  fault  can  be  isolated),  it  compresses  an  AG  output  response  into  a  signature. 
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and  it  transfers  data  from  input  to  output  without  performing  any  iogie  operation  on 
it.  These  functions  are  illustrated  in  the  following  senuence: 


ctrll  otrlO  Function 


0 

0 

1 


1 


0  Parallel  transfer  of  inputs  from  ’iinlldrir' 
to  ‘‘dout[16:li’’ 

1  Test  pattern  generator  outputs  at  ■'allhrij’' 
are  passed  on  to  the  normal  data  outputs 

0  “dout[l6:lj”:  simultaneously,  normal  data 
inputs  at  ”dln[l6:l|"  are  passed  on  to  the 
signature  analyzer  inputs  at  ffllh:!]" 

1  During  this  test  mode,  test  pattern  generator 
outputs  at  “a(l6:l]”  are  pjissed  on  to  the 
signature  analyzer  inputs  at 


Signature  Analyzer  Modes  of  Operation 
Cll  C2l  Function 

0  1  Serial  shifting  of  data  in  the  signature 

analyzer 

1  1  Parallel  data  vectors  at  "d[l6:l]”  are 

compressed  into  a  signature  at  “q[l6:l]” 
outputs,  provided  the  latched  value  of 
“sashiften”  is  high 


Incorporation  of  the  Testing-switch  Modules  into  Design 

A  hardware  design  will  be  partitioned  into  ambiguity  groups  (AGs)  of  intercon¬ 
nected  chips  prior  to  the  incorporation  of  the  testing-switch  modules.  The  example  in 
Figure  6  shows  their  incorporation  in  a  design. 
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.\l*ter  BIT  Module 
Inoorporardon 


Figure  d.  Example  Showing  the  Incorporation  of  the 


Testing-switch  Modules  in  a  Design 


•■^s  evident  from  the  figure,  ail  inputs  to  an  AG  pass  through  a  testing-switch 
module,  and  the  AG  outputs  are  connected  to  the  ‘Min”  port  of  another  testing-switch 
module.  Another  example  illustrating  the  use  of  the  testing-switch  modules  is  shown 
in  Figure  7. 


Before  BIT  Module 
Incorporation 


After  BIT 

Module 

Incorporation 


Figure  7.  Another  Example  Illustrating  the  Incorporation  of  the 
Testing-switch  Modules  in  a  Design 
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A  r,esc  ooncrol  'inic  ^  TCU'i  Is  assumed  to  be  present  In  the  system  in  order  to  per- 


‘brni  'he  ^'oilowiug  I'lincrions: 


L.  CheeKing  'he  ['uncrionaiity  oi  the  testing-switch  moduies: 

2.  Providing  leterminisiic  patterns  to  the  AG  under  test,  if  necessary,  by  shifting  in 
data  throngn  "gendatain''  input  of  the  relevant  testing-switch  module(s); 

3.  Collecting  test  responses  ii.e..  final  signatures’)  through  “satout”  nodes  of  the 
testing-switch  moduies;  performing  necessary  comparisons  with  the  expected  sig¬ 
natures:  and  evaluating  the  status  of  the  AGs; 

4.  Providing  ail  the  necessary  control  signals  to  properly  control  the  operation  of  the 
testing-switch  modules; 

5.  Exercising  proper  control  over  the  AG  clocks  and  the  testing-switch  module 
clocks. 

Before  discussing  a  detailed  procedure  for  testing  the  AGs.  the  following  issues  are 
to  be  considered; 


1.  It  may  be  preferable  to  treat  the  control  inputs  of  an  AG  differently  from  its  data 
inputs  and  to  use  different  testing-switch  modules  in  conjunction  with  control  and 
data  inputs,  as  shown  in  Figure  8. 


Before 

BIT  Insertion 


Control 

Inputs 

Data 

Inputs 


■> 


AG 


Outputs 

- 


(Figure  8  continued) 
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After 

BIT  Insertion 


Figure  8.  Example  Illustrating  the  Use  of  Different  Testing-switch 
Modules  at  Control  and  Data  Inputs  of  an  AG 

This  feature  facilitates  the  application  of  deterministic  test  patterns  at  the  control 
inputs  of  an  AG,  while  allowing  pseudorandom  patterns  to  be  applied  at  its  data 
inputs.  It  is  also  conceivable  to  pass  only  the  data  inputs  of  an  AG  through  a 
testing-switch  module  while  allowing  the  control  inputs  to  be  directly  connected, 
as  shown  in  Figure  9. 


Figure  9.  Example  in  which  a  Testing-switch  Module  is 
Used  Only  at  the  Data  Inputs  of  an  AG 
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In  such  a  scheme,  it  is  generally  assumed  *nat  die  AGs  diac  generate  die  'loat-rol 
inputs  are  tested  first,  and  their  outputs  are  set  ro  iesir^ii  ••aiues  luring  die  "esc 
of  other  .^Gs.  The  feasibility  of  properly  impiemeiirinu  diis  scheme  iepends  an 
factors  such  as  the  design  of  AGs  in  the  system  and  renuired  fault  'soiatioii  resolu¬ 
tion,  and  this  scheme  is  not  considered  in  the  test  procedure  given  subseqimiitly. 

2.  If  the  number  of  inputs  or  outputs  of  an  AG  exceed  cue  iefatiit  .vcu-d-size  of  'he 
testing-switch,  multiple  testing-switch  modules  are  required.  However,  the  test 
pattern  generators  and  the  signature  analyzers  in  different  testing-switch  modules 
need  to  be  used  independently,  i.e.,  they  cannot  be  used  to  form  equivalent  larger 
word-size  modules.  This  is  not  a  limitation  in  general,  since  the  test  pattern  gen¬ 
erator  in  Figure  3  has  the  programmable  feedback  feature  and  it  can  generate 
maximal  length  (2^®— 1)  nonrepetitive  test  vectors.  Furthermore,  uncorrelrted  test 
vectors  can  be  generated  by  initializing  the  various  testing-switches  in  the  system 
with  different  seeds  (initial  test  patterns).  Also,  the  error  escape  probability  asso¬ 
ciated  with  the  signature  analyzer  of  Figure  -4  is  acceptably  low.  i.e..  < 

3.  Proper  setting  of  the  testing-switches  in  the  system  plays  an  important  role  in  the 
overall  test  process.  Such  setting  of  the  testing-switches  can  be  in  a  predeter¬ 
mined  order,  as  shown  in  Figure  10,  or  in  an  arbitrary  order,  as  shown  in  Figure 
11.  In  Figure  10,  “enabin”  to  “enabout’’  delay  may  have  to  be  several 
tphil/tphi2  clock  periods  for  proper  initialization  of  the  testing-switches.  With 
this  requirement  in  perspective,  “clkT’  and  “clk2”  inputs  of  the  enabin-enabout 
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iTiD-ilOtJ  are  separated  :'rom  'he  '‘pnii'’  and  ■"■.pQi2'’  ciocks.  Aroiirary-order  set¬ 
ting  of  the  tescing-swi tones,  'n  general,  requires  a  decoder  as  saown  in  Figure  11. 
In  this  scheme,  tne  ■enauour.'’  jutput  pin  and  the  ‘‘cikl'’  and  ”cik2’'  input  pins 
of  the  testing-switch  are  not  itiiined. 


“naoout  ■'naum 


4naoout  enabin 


3W 


rvV 


sw 


Figure  10.  Scheme  for  Predecermined-order  Setting  of  the  Testing-switches 


From  Test  Control  Unit 

Figure  11.  Scheme  for  Arbitrary-order  Setting  of  the  Testing-switches 
Procedure  for  Testing  AGs 
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Preliminary  Steps 


1.  Reser,  -ill  ‘lie  'estiu'^-switca  aiouuies  iu  ilie  design  by  applying  '‘reset/’  “resell." 
and  ■‘resec'J’’  signals. 

2.  Select  eacdi  "esting-'witcli  ay  means  of  its  “ena’Din'’  signal,  initialize  the  test  pat- 
.ern  generator  and  the  signature  analyzer,  and  enable  the  test  pattern  generator 
to  signature  analyzer  path  i“'trir’  =  1,  ‘'ctrlO”  =  1).  After  a  predetermined 
number  of  clocic  -ycles.  shift  out  the  signature  through  ‘‘satout”  node  and  check 
against  the  expected  signature,  if  an  erroneous  signature  is  noticed,  the  testing- 
switch  module  itself  could  be  faulty  and  might  have  to  be  replaced. 

3.  Perform  reset  fpreset)  of  all  AGs  and  enable  the  normal  data  inputs  to  signature 
analyzer  path  in  each  relevant  tesiing-switch  (“ctrll”  =  1,  “ctrlO”  =  0  —  or 
■‘ctrll’’  =  0,  “ccriO”  =  11.  After  one  clock  cycle  (i.e.,  signature  analyzer  acts  as  a 
parallei-in/serisl-.’iit  register),  shift  out  the  signature  analyzer  contents  and  check 
whether  the  AG  outputs  are  indeed  reset  (preset).  If  this  test  fails,  fault  isolation 
is  generally  to  an  AG-cesting-switch(es)  combination  under  the  single  faulty  AG 
assumption. 


AG  Testing 


4,  Identify  the  .\Gs  in  the  design  that  can  be  simultaneously  tested.  For  instance, 

the  AGs  1  and  2  m  Figure  6  can  be  simultaneously  tested,  whereas,  the  AGs  of 

Figure  7  may  not  be  simultaneously  testable.  Simultaneous  testing  of  AGs  is  not 

always  possible  because  of  the  requirement  that  certain  AG  outputs  must  be  kept 
at  predetermined  states  while  testing  other  AGs.  If  simultaneously  testable  AGs 
do  not  exist  or  have  already  been  tested,  then  pick  a  not-yet-tested  AG  (if  one 
exists)  based  on  a  predetermined  order. 


5.  Bring  all  the  AGs  into  predetermined  and  well-defined  states  by  means  of  global 
control  signals,  such  as  reset  and  preset,  and  then  disable  the  .\G  clocks  from 
further  altering  their  state.  Select  the  testing-switches  associated  with  the  AG(s) 
in  step  4,  one  by  one,  and  perform  the  required  initialization  of  the  associated  test 
pattern  generators  and  signature  analyzers.  The  initialization  process  involves 
such  steps  as  programming  the  feedback  polynomial  of  the  test  pattern  genera¬ 
tors;  shifting  in  the  initial  seed;  and  proper  setting  of  the  various  control  signals, 
such  as  ‘‘genctrlin,”  “genshiften,’’  “ctrllin,’’  “ctrlOin,’’  “saclin.”  and  “sac2in.'’ 


6.  Enable  the  AG  clocks,  and  ensure  that  they  bear  appropriate  frequency  and  phase 
relationship  with  t.,e  test  clocks  tphil/tphi2.  The  pseudorandom  test  patterns 
generated  by  the  test  pattern  generators  in  the  testing-switch  modules  will  be 
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applied  to  the  relevant  AG(s').  and  iheir  responses  H’iil  ccinDr-'ssf';  -^v  :i;e  sig¬ 
nature  analyzers  in  '.he  'esLinir-switohes.  Conrroi  ^npurs  o  .V'h.-  ’an  se  ir 

desired  logic  values  by  using  the  iisabie-shift  capabiiity  a'  iie  -s'  :  :u .‘S'.i- 
erators  in  the  tesring-swicch  moduies. 

7.  •‘Vfter  a  predetermined  number  oi‘  clock  cycles,  apply  ■’reset; I  '  'ignai  um  lisauie 
shifting  in  all  the  signarure  analyzers.  Then,  seiecr  eacii  ■'^ii-vanc  signar.ur'" 
analyzer  by  means  of  "enabin'’  signal  of  the  associated  'esring-'V-ircti.  mo  shift 
out  the  stored  signature.  Compare  this  signature  .vith  the  -xpecreo  tine,  ontained 
a  priori  from  simulation,  and  determine  the  status  of  AGis). 

8.  Repeat  steps  5  through  7  for  all  the  necessary  control  modes  of  'tie  .CGhs). 

The  above  AG  test  procedure  is  repeated  until  all  the  AGs  are  tested.  If  the  test 
of  an  AG  fails,  fault  isolation  is  generally  to  the  combination  of  an  AG.  the  :issoc:ated 
testing-switches,  and  the  inherent  interconnections. 


Timing  Considerations 

The  outputs  “dout[16:lj”  assume  the  values  of  ■•din[l6:l]”  (normal  ilaia  inputs), 
or  “a[l6:l]”  (test  pattern  generator  outputs),  or  “1”  (logic  one)  with  one  clock  cycle 
delay  after  the  “ctrUin’’  and  “ctrlOin”  values  change.  Figure  12  illustrates  this  aspect. 
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ADDITIONAL  LOGIC  ASSOCIATED  WITH  THE 
VERSION-2  BIT  MODULES 


Objective 

The  purpose  of  rhiis  :iote  's  ‘o  describe  ■'he  addicionai  logic  incorporated  into  the 
Version-2  BIT  modules  in  order  to  make  rhem  directly  compatible  with  the  mainte¬ 
nance  node  unit  (MN)  described  in  the  application  note  entitled  Maintenance  Node. 

Block  Diagram 


resetp 

id_in 

cdi_phil 

cdi_phi2 


BIT  Module 
I  Version- 1 ) 
enable 


Additional  Logic 


I - - 


T'frrr'K  %  ^ 


: - - 1 


ag_enable 


->•  ag  reset 


-»■  ag_preset 


Figure  1.  Block  Diagram  Showing  the  Inputs  and  Outputs  of  the 
Additional  Logic  Associated  with  the  Ver5ion-2  BIT  Modules 
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Pin  Description  fSee  also  the  logic  diagram  and  the  application  note  on  the 
utilization  of  the  MN) 


Name 

ag[4:0l 
ag_p  reset, 

ag_reset 

bit_id  [2:0] 
breset 

cdi_phil.  edi_piii 

comp 

ag_enable 

id_in 

id_load 

resetp 


Description 

■5-'oit  ambiguity  group  (AG)  id  (geaeraily  hardwired) 

Output  signal  to  indicate  that  the  ‘‘preset”  of  the  AG 
outputs  is  required 

Output  sign-ai  to  indicate  that  the  “reset”  of  the  AG 
outputs  is  required 

:>-bit  BIT  module  id  (generally  hardwired) 

Board- reset  signal  generated  by  the  MN 

Non-overlapping  phases  of  the  GDI  clock 
generated  by  the  VIN 

"Compare  successful”  signal  generated  by  the  MN 

Output  generated  by  the  additional  logic  in  the 
BIT  module.  It  is  connected  to  the  ‘‘enable”  input  of  the 
version-!  BIT  module,  as  shown  in  figure  1.  It  may  also  be 
connected  to  the  tristate  control  input(s)  of  the  version-1  BIT 
module. 

Serial  identification-address  input 

The  ‘‘identificationjoad”  signal  generated  by  the  MN 

The  ‘‘power-on”  reset  of  the  additional  logic  block 
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Logic  Description 


Figure  2  illustrates  the  additional  logic  incorporatea.  vhiie  dgni’^'  -  ^iious  u  :iicrp 
detailed  description  used  in  the  C.\DAT  simulation.  The  C.\i) AT  iescrinrion  ises 
primitives  such  as  “dff-1,'’  ‘'nlmos,''  '‘comparator,"  ‘‘decbin"  decoaeiv.  jnd  •huf  in 
addition  to  the  basic  gates. 

Timing  Considerations 

Figure  4  shows  a  data  sequence  required  to  be  input  through  "id_in  ’  in  order  to 
raise  the  “enable”  signal  to  high  level.  Once  the  ‘‘enable"  signal  becomes  high,  the 
BIT  module  accepts  data  and  control  signals  through  its  relevant  inputs.  The  “comp" 
and  “breset”  signals  are  generated  by  the  MiNh  and  it  is  assumed  that  the  ‘‘breset”  sig¬ 
nal  is  low  for  this  e.xample.  The  ‘d-blt  AG  preset/reset  command  code  is  chosen  such 
that  the  “ag_reset”  output  is  activated.  Finally,  all  the  hardwired  id  values  are 
assumed  to  be  all  “I's”  for  simplicity.  The  “enable”  signal  may  be  brought  to  low' 
level  when  needed  by  following  the  same  sequence  with  a  different  3-bit  BIT  module 
id. 
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AG  preset  AG  reset 


Figure  2.  Additional  Logic  Associated  with  BIT  Modules  to  Generate  the  Itequired  'I'etit  Sigiial^j 
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Figure  3.  A  Detailed  Description  of  the  "Additional  Logic"  Block  Used  in  Version-2  BIT  Modules 
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MISCELLANEOUS  MODULES  TO  AID  TESTING 


Objective 

The  objective  of  this  application  note  Is  to  describe  a  collection  of  miscellaneous 
modules  which  are  part  of  the  BIT  module  library  supplied  with  TEA. 

Module  1  :  MUX2X8 

MUX2X8  is  a  multiplexor  which  allows  the  selection  of  one  of  two  sets  of  S  input 
lines.  This  module  is  shown  in  Figure  1  and  is  used  in  some  BIT  techniques  as  a  means 
of  selecting  either  “normal”  input  or  “test”  input. 


Select 


Figure  1.  A  Block  Diagram  of  the  \'IUX2X8  Module 
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Module  2  :  MUX4X8 


MUX4X8  is  a  muitiplexor  which  ailows  rtie  se-ecihon  ..m'  )ae  A  four  -er.s  of  5  input 
lines.  This  module  is  shown  in  Figure  'J  and  is  used  in  some  BIT  recaniques  is  a  means 
of  arbitrating  among  the  ambiguity  group  outputs  ready  tor  a  signature  analyzer. 

SelectO 
Select  I 

Figure  2.  A  Block  Diagram  of  the  MTX4X8  Module 

Module  3  :  MUX2 

MUX2  is  a  multiplexor  which  allows  the  selection  of  one  of  two  sets  of  16  input 
lines.  This  module  is  shown  in  Figure  3  and  is  used  in  some  BIT  techniques  as  a  means 
of  selecting  either  “normal”  input  or  “test”  input. 
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Figure  3.  A  Block  Diagram  of  the  \[LiX2  VIodule 
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Module  4:  MUXi 


MLX4  is  a  n.imtipie':or  'vnica  aiiows  ntie  selection  ot  one  of  four  sets  of  16  input 
lines.  This  oioduie  is  :5nown  in  Figure  4  and  is  used  in  BIT  techniques  to  select  a  por¬ 
tion  of  output  lines  'o  he  roared  to  a  signature  analyzer. 
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Figure  4.  Block  Diagram  of  the  MLX4  Module 


Module  5  :  ZEROS 


ZEROS  always  has  a  low  (‘0’)  signal  on  its  16  output  lines.  There  are  no  inputs  to 
the  module.  This  module  Is  shown  in  Figure  5.  The  module  is  used  to  provide  inputs 
to  devices  expecting  inputs  on  all  of  its  lines  (e.g.,  8-bit  comparator). 
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Module  6  :  ONES 


ONES  always  lias  a  high  (/I''  signal  dn  ics  1(5  oncpui  'iii^s.  Tliero  -re  no  inputs  to 
the  module.  This  module  is  shown  in  Figure  :5.  The  monuie  '.s  used  \o  provide  inputs 
to  devices  expecting  inputs  on  all  of  its  lines  (e.g.,  S-bit  ..•omnarator  i. 
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OVERVIEW 


This  instailacion  guide  describes  the  .\DAS/TEA  system  instailacioii.  This  guide  is 
divided  into  several  major  sections,  which  are  listed  in  the  table  of  ooiiceucs: 

1.  Setting  Up  Hardware  —  describes  workstation  switch  settings  and  interconnec¬ 
tions.  mouse  calibration,  and  plotter  pen  order. 

2.  The  Installation  Process  —  describes  each  step  in  the  ADAS/TEA  installation 
process  for  both  new  installations  and  system  upgrades.  Each  installation  step 
begins  on  a  new  page:  these  steps  must  be  performed  in  the  sequence  presented  to 
ensure  the  system  is  installed  correctly. 

3.  Sample  Graphics.dat  and  Hardcopy.dat  Files  —  discusses  the  contents  of  these 
files  and  Illustrates  their  interconnections. 

4.  Graphics.dat  Device  Flags  —  describes  all  flags  associated  with  entries  in  the  file 
'  and  gives  their  value  ranges. 

5.  Troubleshooting  the  Installation  Process  —  provides  guidelines  for  correcting 
problems  during  the  installation  process. 

If  you  have  problems  installing  ADAS/TEA,  or  questions  that  this  guide  does  not 
address,  contact  Jill  Hallenbeck  at  919-541-7413| 

NOTES 

This  is  an  installation  guide  for  installation  of  the  prototype  TEA  code  on  a  Micro V.AX 
II/GPX  running  VXIS.  It  is  our  intent  to  minimally  disturb  regular  .AD .AS  installation 
procedures,  so  more  information  is  provided  than  is  actually  needed. 

.Also,  the  version  of  EDIGRAF  delivered  with  TEA  is  a  version  resulting  from  recent 
Government  contracts,  so  some  added  features  may  be  unfamiliar  to  the  .AD.AS  user. 


p.  1 


TEA 


Installation  Guide 


THE  ADAS/TEA  ENVIRONMENT 


The  TEA  user  needs  a  V'AXstatlon. 

•  Stand-alone  workstations  —  follows  with  at  least  10  .VIb}<nes  of  disk  storage  capa¬ 
city  and  at  least  3  Mbytes  of  working  memory: 

•  VAXstation  II/GPX,  with  VXIS  Operating  system.  Version  4.3  or  later: 

VWS  Version  3.0  or  later;  optional  VAXC  compiler  Version  2.0  or  later; 

and/or  Ada  compiler  with  either  Version  1.3.  1.4,  or  1.5. 

•  VAXstation  2000,  with  VXIS  Operating  system.  Version  4.3  or  later;  \AVS 

Version  3.0  or  later;  optional  VAXC  compiler  V'ersion  2.0  or  later.  The 

monitor  can  be  either  B/W,  4-color  plane,  or  8-color  plane. 

•  Pen  plotter  —  Hewlett-Packard  Plotters,  Model  7220-C,  Model  7585-B,  Model 
7550,  and  Model  7475-A.  All  plotters  must  be  connected  to  their  own  ports  on  the 
host  computer. 

•  Laser  printer  —  Imagen  Imprint-10  and  8/300  and  other  PostScript-supported 
laser  printers. 

If  the  current  version  of  VMS  is  not  4.7,  then  .AD.A.S  must  be  relinked.  Other  errors 
that  may  be  encountered  during  the  installation  process  are  described  later  in  this 
guide,  in  the  section  entitled  Troubleshooting  the  Installation  Process. 

The  VAXstation  Environment 

The  connection  of  the  VAX  mouse  to  the  VAXstation  monitor  is  straightforward  and  is 
well-documented  in  the  VAXstation  manual. 

By  default,  TEA  creates  a  square  graphics  display  window  when  an  interactive  TE.A 
tool  is  invoked  that  is  13  cm  by  13  cm.  The  TEA  user  can  change  the  dimensions  of 
this  window  by  entering  the  command 

$  define  gterin_slze  nn 

where  nn  is  the  size  of  the  window  in  centimeters  (maximum  dimension  is  25  cm  by  25 
cm).  The  graphics  window  created  by  TEA  can  be  repositioned  like  any  other  window. 
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SETTING  UP  THE  PLOTTER 

Plotter  Switch  Settings 


1.  Hewlett-Packard  Model  747o-A 


Sec  che  switches  on  the  back  side  of  the  plotter  as  follows: 


1200  baud 
2400  baud 
4800  baud 
9600  baud 


S2  SI  Y 

0  0  0 

0  0  0 

0  0  0 

0  0  0 


Switch  Setting 
US  A3  B4  B3 

10  0  1 

10  10 

10  10 

10  10 


B2  Bl 
1  1 
0  0 
0  1 
1  0 


2.  Hewlett-Packard  Model  7585-B 

Set  the  interface  mode  switch  (HP-IB/RS-232-C)  on  the  back  side  of  the  plotter  to  the 
RS-232-C  position. 

Set  the  rotary  switch  at  the  bottom  of  the  switch  block  to  2400  baud. 

Set  the  switches  to  the  right  of  the  interface  mode  switch  as  follows: 

1.  Set  EXPAND/NORMAL  to  NORMAL. 

2.  Set  EMULATE/NORMAL  to  NORMAL. 

3.  Set  STAND  ALONE/EAVESDROP  to  STAND  ALONE. 

4.  Set  MONITOR  MODE/NORMAL  to  NORMAL. 

.5.  Set  LOCAL/NORMAL  to  NORMAL. 

Set  the  switches  in  the  RS-232-C  section  as  follows: 

1.  Set  PARITY  ON/OFF  to  OFF. 

2.  Set  PARITY  EVEN/ODD  to  ODD. 

3.  Set  DUPLEX  HALF/FULL  to  FULL. 

4.  Set  HARDWIRE/MODEM  to  MODEM. 

5.  Set  DTR  BYPASS/NORM  to  NORM. 
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SETTING  UP  THE  PLOTTER 

Pen  Color  Order 


For  Hewlett  Packard  plotters  that  have  etght  pens  (7d50-A,  7220-C.  7585-B),  insert  the 
pens  into  the  following  carriage  positions: 


1  -  red 

2  -  blue 

3  -  green 

4  -  black 


5  -  yellow 

6  -  purple 

7  -  brown 
S  -  orange 


For  Hewlett  Packard  plotters  that  have  six  pens  (7475-A),  insert  the  pens  into  the  fol¬ 
lowing  carriage  positions: 


1  -  red 

2  -  blue 

3  -  green 


4  -  black 

5  -  yellow 

6  -  purple 
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The  Installai^ion  Process 


STEP  ONE:  READING  THE  ADAS/TEA  INSTALLATION  T.APE 

A.  Tape  File  Structure  and  Contents 


The  .\DAS/TEA  disr,ribacion  oape  is  a  nine-track,  1600  bpi  or  TKoO  V.kX,  VAIS 
backup  format  tape.  The  TEA  instailation  process  will  create  the  following  'iirectory 
structure,  where  dev:  is  the  device  that  holds  the  installation  files: 

dev.' [adas  .  conf  Ig]  Contains  graphics.dat  and  hardcopy.dat  configuration 

files.  Sample  files  are  generated  during  the  Installa¬ 
tion:  these  will  have  to  be  edited  using  the  informa¬ 
tion  in  this  guide  to  customize  the  instailation  for 
your  site. 

dev:  [adas  .  dlst .  bln]  Contains  the  ADAS/TEA  program  executable  files. 

dev:  [adas  .  dlst .  help]  Contains  the  ^ADAS/TE.A  help  files. 

dev:  [adas  .  dish .  Include]  Contains  CSIIVIGEN  include  files  for  the  CsimDb 

data  base  access  routines. 

dev:  [adas  .  dlst .  lib]  Contains  color  map  files  and  master  graph  com¬ 

ponent  template  files. 

dev:  [adas  .  dlst .  obj  ]  Contains  object  files  for  relinking  the  bin  directory. 
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The  Installation  Process 


STEP  ONE:  READING  THE  ADAS  INST.ALLATION  TAPE 

B.  Creating  An  ADAS  Directory 


Before  performing  "his  step,  be  sure  to  check  for  any  instailatiou  instrucrious  pacirea 
with  the  release  cape,  since  these  couJd  affect  the  procedures  beiow. 

•  Create  a  directory  for  the  ADAS  system  Hies.  The  preferred  name  for  this  lirec- 
tory  Is  adas.  and  its  preferred  location  is  directly  In  a  device's  master  file  direc¬ 
tory.  The  following  example  creates  directory  adas  in  a  master  file  directory 
named  dra^: 


$  create/dlr  dra2: [adas] 

f  rrta  J ”■  i  ■  ■  ■  t  /I  'j 

•  If  this  is  a  new  installation,  or  if  the  user  "‘adas’’  does  not  already  exist  on  the 
system,  then  add  the  user  “adas”  with  a  home  directory  of  dra-3:[ndasl. 

•  Define  a  systemwide  logical  named  adas  that  will  reference  the  .ADAS  root  direc¬ 
tory.  For  example. 

$  def Ine/system  adas  dra2: [adas . ] /translatlon=concealed 
This  will  allow  you  to  access  files  by  using  the  path  names  in  the  user  manual. 
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The  Installation  Process 


STEP  ONE:  READING  THE  ADAS/TEA  INSTALLATION  TAPE 

C.  Extracting  The  Tape  Contents 


Login  IS  'adas’’  and  extract  the  contents  of  the  tape  into  the  new  directory  using  the 
backup  command.  The  following  example  assumes  the  tape  drive  is  named  msaO:  and 
places  all  .ADAS  tiles  and  directories  from  the  tape  in  directories  adas:[configj,  and 
adas:i(iistj. 


$  seti  default  adas :  [000000] 

$  mount/foreign  msaO:  adas  tape 
$  backup/rewlnd/verlfy  tape : adas . save  [*...] 
$  dismount  tape 
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The  Installation  Process 


STEP  TWO:  CREATING  FILE  GRAPHICS.DAT 


File  adas: lconfigjgraphics.dat  contains  information  that  associates  input  and  output 
devices  with  logical  workstations  and  assigns  names  to  the  workstations.  The  file  is 
divided  into  two  parts  separated  by  a  line  containing  two  percent  signs  {%%).  Lines 
beginning  with  a  pound  sign  (#)  are  comment  lines.  Their  contents  are  ignored.  A 
sample  graphics.dat  file  is  supplied  with  the  installation  tape;  it  can  be  edited  to  cus¬ 
tomize  it  for  your  site’s  workstation  configuration.  Examine  this  file  and  the 
graphics.dat  example  later  in  this  guide  to  become  familiar  with  the  structure  and  con¬ 
tents  of  the  file. 

The  first  part  of  the  file  describes  logical  workstations  and  their  characteristics.  Each 
line  of  the  file  describes  a  single  graphics  workstation  or  hardcopy  device  and  contains 
several  fields  separated  by  blanks  (the  values  of  out_type,  in_type,  and  flagi-valuei 
are  listed  later  in  this  guide,  in  the  section  Graphics.dat  Device  Flags  and  Their 
Values): 

work  name  out  type  out  name  in_type  in  name  [flagl=valuel  ...] 


where: 


work  name 


out  type 
out_name 

in_type 

in_name 

flagi=valuei 


is  the  name  of  the  workstation  or  hardcopy  device  as  entered  by  a 
user  when  invoking  an  ADAS  program;  it  can  be  any  alphanumeric 
value,  but  workstation  names  must  use  lower  case  letters  only  and 
hardcopy  device  name  must  be  no  longer  than  18  characters  (e.g., 
rasi,  bwplot). 

is  the  output  device  type;  legal  values  are  listed  later  in  this  guide 
(e.g.,  rasbech,  Imagen). 

is  the  physical  name  of  the  output  device  described  in  the  second  half 
of  the  file;  it  can  be  any  alphanumeric  value,  but  it  must  use  lower 
case  letters  only  (e.g.,  rast,  hpplotlg). 

is  the  input  device  type;  legal  values  are  listed  later  in  this  guide  (e.g., 
summa,  vsllbab). 

is  the  physical  name  of  the  input  device  described  in  the  second  half 
of  the  file;  it  can  be  any  alphanumeric  value,  but  it  must  use  lower 
case  letters  only  (e.g.,  rasl). 

is  one  or  more  device-dependent  flags  associated  with  the  workstation 
or  hardcopy  device.  There  are  flags  for  device  type,  device  model, 
plot  color  and  fill  modes,  laser  printer  resolution,  and  laser  printer 
output  disposition.  These  flags  are  described  later  in  this  guide. 


p.  8 


TEA 


Installation  Guide 


The  Instailatioa  Process 


The  second  of  the  file  describes  paths  "o  actual  ptiysical  oevices.  oacli  ;iie  ;i'  iie 

file  describes  a  siu'^ie  ptiysicMi  device  and  lourains  'our  aiLuiuauu-;.'  feias  'ervirai -o  . 

blanks: 

ciev_name  conn  type  hard  name  speed 

where: 

dev_name  Is  the  physical  device  name  as  specified  In  the  first  part  of  the  file  'see 
the  descriptions  of  out_name  and  in_name  above';. 

conn_type  Is  the  connection  type:  the  oniy  vaiia  connection  type  at  present  's  a 
capita!  N. 

hard_name  is  the  hardware  name  for  the  device:  this  will  usually  be  the  name  of 
the  terminal  line  to  which  the  device  is  connected.  Some  devices  may 
have  their  own  controllers,  however,  and  will  not  be  attached  to  a  ter¬ 
minal  line. 

speed  is  the  baud  rate  for  the  line  to  which  the  device  is  connected.  This 

field  can  be  set  to  the  value  ignore  If  the  speed  does  net  have  to  be 
set  for  the  device  (l.e.,  for  a  device  with  its  own  controller). 


The  Installation  Process 


STEP  THREE:  CREATINC  FILE  H.4RDCOPY.DAT 


File  (idas::c()nfigihtirfici)py.dnt  (‘onoains  the  names  oi  ail  anmeopy  .levices  'iescribe>i  'n 
fiie  graphics,  daf.  ana  is  ased  to  generate:  a  menu  oi‘  hardcopy  levices  in  'he  .AJ)Ad  aser 
interface.  A  sample  hardcopy,  dat  file  is  suppiiea  '.vith  the  instaiiation  ':.pe;  it  can  he 
edited  to  customize  it  fur  your  site's  workstation  configuration.  E::amine  this  file  and 
the  hardcopy.dat.  a.xample  later  in  this  guide  to  become  familiar  with  the  structure  and 
contents  of  the  file.  .All  entries  in  the  file  must  be  aipnanumeric.  must  begin  with  a 
letter,  and  can  be  up  to  18  characters  long.  Each  line  of  the  file  contains  the  nam”  of 
a  single  hardcopy  device. 


TEA 
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The  Installation  Process 


STEP  FOUR:  MODIFYING  THE  SYSTEM  START-UP  PROCEDURE 


Edit  the  system  start-up  file  sys^manager: systartup.com  to  set  the  protection  on  the 
output  terminal  devices  specified  in  the  second  part  of  file  graphics.dat  as  follows: 

$  set  prot=w:rwlp  hard_na7ne/ device 

where  hardjname  is  the  hardware  name  for  the  device  as  specified  in  graphics.dat.  For 
the  sample  graphics.dat  file  later  in  this  guide,  the  entries  in  the  system  start-up  file 
would  look  like  the  following: 

$  set  prot=w:rwlp  ttbO:/devlce 
$  set  prot=w:rwlp  ttbl: /device 
$  set  prot=w:rwlp  ttb2:/devlce 
$  set  prot=w:rwlp  ttb3:/devlce 

Add  the  following  line  to  the  system  start-up  file  to  initialize  the  ADAS  system: 

$  @adas: [dlst.bln]run_monltor 
Edit  the  user’s  login.com  file  to  execute  the  ADAS  setup  file: 

$  @adas : [dlst] setup 

NOTE:  It  is  not  recommended  that  a  graphics  device  be  attached  to  Port  0  or  Port  1 
of  a  DMF-32  because  of  the  complex  communication  requirements.  Another  recom¬ 
mendation  is  that  the  terminal  line  to  each  graphics  device  be  set  to  “no  broadcast.’" 
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The  Installation  Process 


STEP  FIVE:  CHECKING  THE  INSTALLATION 


Go  to  the  ADAS  User  Manual  and  try  executing  the  Add  Command  Tutorial  .  page 
7-8.  If  the  following  error  message  appears,  the  programs  need  to  be  relinked; 

%DCL-W-ACTIMAGE ,  error  activating  Image  name 
-CLI-E-IMGNAME,  Image  file  filename 

-SYSTEM-F-SHRIDMISMAT,  Ident  mismatch  with  shareable  Image 


To  relink  the  programs,  execute  the  ADAS  linkage  command  file  as  follows: 

$  set  def  adas: [dlst.obj] 

$  ©link 


See  the  note  on  ADAS  on  page  2. 
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The  Installation  Process 


A  SAMPLE  GRAPHICS.DAT  FILE 


riie  foilou-iii!;  '"xainpie. 


Figure  I.  illustrates  a  eomDiece  qravn-n'-'-.iint  ;'iie. 


rasL  rastecr.  rasl  rastab  rasi  aodei=40 

ras2  rasteca  ras2  aouse  ras2tab  b7pe=3CaEclari  aodei='.0 

rasl  rasbty  rasT  rasttytab  rasT  aodel=ic 

taScl  belc  belci  teictab  baKi  aodel=4l07  ievice=3 

plot  applotter  plot  aull  aull  type=7585  oolor=oolor 

fall  applottar  plot  aull  aull  type=7585  oolor=Golor  :iil=oa 

awplot  applottar  plot  aull  null  type=7585  color=bw 

iiaagen  inagen  aull  aull  aull  ''command=print/que=laser/delete  7s“  rasolution=240 
lafile  ’.!a_:ile  aull  aull  null  resolution=300  * 

imflle2  imagen  aull  aull  aull  “Gomiaaad=rename  %s  adas  imagan  outout"  rasolution 
'rsii  7S11  aull  vsiitab  aull  Golor=color  ~ 

VS2000  7S11  aull  7siitab  aull  color=color9 
vsiibw  vsii  null  vsiitab  aull  oolor=bw 
hpfile  ap_:ile  null  null  null  type=7220  color=color 
postscript  Dostscript  null  null  null  resolution=300 
^555 

rasl  M  ttbC:  9600 
ras2  N  ttbl  9600 
ras2tab  M  ttb2:  1200 
rasT  N  ttb3:  9600 
plot  N  ttb4.  2400 
tekl  N  ttb5:  9600 


Figure  1.  Contents  of  graphics.dat 


In  Figure  1, 

rasl  represents  a  Raster  Technologies  Model  1/40  graphics  terminal  that  has  an 
unspecified  type  of  mouse  or  data  tablet  attached  directly  to  it.  The  rasl  ter¬ 
minal  is  connected  to  line  ttbO  and  runs  at  9600  baud. 

ras2  represents  a  Raster  Technologies  Model  1/10  that  has  a  Mouse  Systems  Model 
M-1  attached  directly  to  the  computer  rather  than  into  tlm  graphics  terminal. 
The  ras2  terminal  is  connected  to  line  ttbl  and  runs  at  9600  baud.  The 
mouse  is  connected  to  line  ttb2  and  runs  at  1200  baud. 

rasT  represents  a  Raster  Technologies  Model  1/10  that  will  simultaneously  display 
text  (in  the  lower  8  rows)  and  graphics.  This  eliminates  the  need  for  an  addi¬ 
tional  VTlOO  terminal.  The  rasT  terminal  is  connected  to  line  ttbS  and  runs 
at  9600. 

vsll  represents  a  color  V.\Xstatlon  11/GPX.  Note  that  the  logical  input  and  output 
devices  are  null  because  there  is  only  one  software  display  and  the  software 
knows  where  to  find  it. 
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A  Sample  jraphicu.iiai  and  hardcnvij.dat  Setup 


'/S2000 

/silbw 

teicl 

plob 

r  4  *•  ? 

'owplot 

Imagen 

Imflle 

Imf lle2 

hpflle 

postscript 


represents  a  coior  V'.\Xsf.:ition  vvith  4  -.-olor  pianes.  Nore  die 
oolor=color9  entry  '.vnk-ii  is  necessary  ;'or  die  4  joior  iiane  I'eature. 

renresents  a  black- and-white  iispiar  I'ar  a  V.^dvstation.  Xore  -iie 
color='ow  entry  necessary  :'or  '.iiis  eature. 

represents  a  Tektronix  Model  4107  ^r-ap tiles  erniinai  '.vitii  a  Tektronix 
0)57  data  tablet  attacned  directly  to  It.  The  tekl  terminal  Is  con¬ 
nected  to  line  ttbS  and  runs  at  0600  baud. 

represents  a  Hewlett-Packard  .Model  7585-3  pen  plotter.  The  entry 
color=color  will  outline  the  nodes  in  color  but  will  not  fill  them.  The 
plotter  is  connected  to  line  number  ppb4  and  runs  at  2400  baud. 

represents  a  Hewlett-Packard  Vlodel  7585-3  pen  plotter.  The  entry 
fill=fill  will  nil  the  entire  node  in  color.  The  plotter  is  connected 
to  line  number  ■Dt.b4  and  runs  at  2400  baud. 

represents  a  Hewlett-Packard  Model  7585-B  pen  plotter.  The  entry 
color=bw  will  outline  the  nodes  in  black  but  will  not  fill  them.  The 
plotter  is  connected  to  iine  number  Pbb4  and  runs  at  2400  baud. 

represents  an  unspecified  model  Imagen  laser  printer  with  a  resolution 
of  240  pi.xels  per  inch.  The  print  commands  are  output  directly  to  an 
Imagen  printer. 

represents  an  interactive  driver  that  allows  the  print  commands,  in 
impress  format,  to  be  output  to  a  file  instead  of  directly  to  the  printer. 
The  generated  file,  named  adas. impress  by  default,  must  be  incor¬ 
porated  into  a  larger  document  since  it  does  not  contain  any  header 
information.  The  entry  Imflle  must  be  added  to  the  hardcopy.dat 
file. 

uses  the  Imagen  driver  to  output  the  print  commands,  in  impress  for¬ 
mat.  to  a  file  instead  of  an  Imagen  printer.  The  generated  file,  named 
adas.imagen_oxitput  by  default,  will  contain  the  necessary  header  infor¬ 
mation  for  printing.  The  entry  lmflle2  must  be  added  to  the 
hardcopy,  dat  file. 

represents  an  interactive  driver  that  will  output  the  Hewlett-Packard 
pen  plotter  commands  to  a  file  instead  of  to  a  plotter.  The  generated 
file,  named  adas.hpplot  by  default,  can  be  printed  using  your  local 
plotter  print  commands.  The  entry  hpflle  must  be  added  to  the 
hardcopy,  dat  file. 

represents  an  interactive  driver  that  will  output  print  commands,  in 
PostScript  format,  to  a  file  named  adas.ps  by  default.  The  re.solution 
will  differ  depending  on  machine  type.  This  file  can  be  printed  using 
your  local  PostScript  print  commands.  The  entry  postscript,  must 
be  added  to  the  hardcopy.dat  file. 
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A  Sample  graphtcs.dat  and  hardcopy. dat  Setup 


HOW  GRAPHICS.DAT  INTERNAL  POINTERS  WORK 


VVhen  an  .\DAS  user  invokes  one  of  the  interactive  tools  (see  Figure  ‘2.  below  i.  rhe 
graphics  device  name  specified  on  the  command  line  must  match  one  of  the  graphics 
device  names  in  file  graphics,  dat.  Note  that  in  Figure  2  the  user  has  specified  device 
rasl,  which  matches  one  of  the  workstation  definition  lines  in  the  first  part  of  file 
graphics. dat.  The  output  and  input  device  physical  names  (rast)  in  the  first  part  of 
file  graphics.dat  connect  the  workstation  description  to  the  physical  device  in  the 
second  part  of  the  file,  rasl  is  a  Raster  Technologies  Model  1/40  device  connected  to 
terminal  line  ttbO  :  running  at  9600  baud. 


Figure  2.  Internal  graphics.dat  Pointers 
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A  Sample  graphics.dat  and  hardcopy. dat  Setup 


A  SAMPLE  HARDCOPY.DAT  FILE 


The  following  example,  Figure  3,  illustrates  a  complete  hardcopy.dat  file  for  the  sample 
graphics.dat  file.  The  three  hardcopy  devices  are  associated  with  hardcopy  device 
names  in  the  graphics.dat  file  entries;  they  are  entered  in  their  order  of  appearance  in 
ADAS  user  interface  menus.  Changing  their  order  in  hardcopy.dat  will  change  their 
order  of  appearance  in  .ADAS  menus. 


plot 

fill 

bwplot 

Imagen 

Imflle 

Imf lle2 

hpflle 

postscript 


Figure  3.  Contents  of  hardcopy.dat 


TEA 


p.  16 


Installation  Guide 


A  Sample  jravhics.dat  a,Dd  hardcopy.dat  Setup 


HOW  HARDCOPY.DAT  INTERNAL  POINTERS  WORK 


When  an  .\DAS  user  selects  the  hardcopy  option  from  the  user  interface  main  menu, 
a  submenu  of  hardcopy  devices  is  displayed  on  the  terminal  screen  isee  Figure  4. 
below).  Device  names  are  displayed  in  their  order  of  occurrence  in  fiie  hardcopy.dat. 
Note  that  in  Figure  4  the  user  has  selected  device  bwpiot.  which  is  the  third  entry  in 
file  hardcopy.dat.  The  hardcopy.dat  entry  matches  one  of  the  workstation/device 
definition  lines  in  file  graphics. dat.  The  output  device  physical  name  (plot)  in  the 
first  part  of  file  grapnics.dat  connects  the  hardcopy  device  description  to  the  physical 
device  in  the  second  part  of  the  file,  bwplot  is  a  Hewlett-Packard  Model  7.585  plotter 
operating  in  black/ white  mode;  it  is  connected  to  terminal  line  tbbS :  running  at  2400 
baud. 


command^  hardcopy 
===  menu  === 
plot 


Figure  4.  hardcopy.dat  and  Its  Interaction  with  graphics.dat 
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GR.4PHICS.DAT  DEVICE  FLAGS  AND  THEIR  VALUES 


1.  Output  Device  Flags 


Second  Tieid.  All  characters  must  be  lower  case.  The  following  output  device  types  are 

supported: 

iipploPPar  Hewlett-Packard  pen  plotter.  Use  the  t;ype  flag  to  select  model,  the 
color  flag  to  select  color  mode,  and  the  fill  flag  to  select  plot  fill 
mode. 

imagen  Imagen  laser  printer.  Third  field  (physical  output  device  name)  must  be 

set  to  null.  Use  the  resolution  flag  to  set  output  resolution  and 
the  ''command=u«/«e"  flag  to  specify  output  disposition. 

rastech  Raster  Technologies  graphics  device.  Use  the  model  flag  to  select 
model. 


tek  Tektronix  terminals.  Use  the  model  flag  to  select  model  and  the  dev¬ 

ice  flag  to  select  input  port  ntimber. 

vsll  V.AXstation.  The  third  field  (physical  output  device  name)  must  be  set 

to  null.  Use  the  color  flag  to  select  either  B/W,  16  colors,  or  256 
colors. 


lm_flle  Imagen  print  to  file.  Use  the  resolution  flag  to  set  output  resolu¬ 
tion. 


hp_flle  Hewlett-Packard  pen  plotter  commands  to  file.  Use  the  color  flag  to 
select  color  mode  and  fill  flag  to  select  plot  fill  mode. 

postscript  Generates  PostScript  format  file  for  printing  on  PostScript-supported 
printers.  Use  the  resolution  flag  to  set  output  resolution. 


2.  Input  Device  Flags 

Fourth  field.  All  characters  must  be  lower  case.  The  following  input  device  types  are 

supported: 

mouse  A  Mouse  Systems  Model  M-1  mouse  or  Summagraphics  SummaMouse 
plugged  directly  into  the  computer.  Use  the  type  flag  to  identify  the 
type  of  mouse. 

rastab  .\ny  type  of  data  tablet  or  mouse  that  is  plugged  directly  into  a  Raster- 
Technologies  Model  l/lO.  1/40,  or  l/60  graphics  device.  No  special  flags 
are  required. 

summa  A  Summagraphics  Bit  Pad  One.  No  special  flags  ai-e  i-equii-ed. 
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null  Indicates  there  is  no  input  device  associated  with  the  entry. 

Uelctab  .\ny  type  of  data  tablet  or  mouse  that  is  plugged  directly  into  a  Tek¬ 

tronix  terminal.  No  special  flags  are  required. 

vslltab  ’Vk-^Xstation  mouse  or  tablet.  The  fifth  field  (physical  input  device  namei 
must  be  set  to  null.  No  special  flags  are  required. 


3.  Workstation  Flags 

Sixth  and  following  fields.  All  characters  must  be  lower  case.  One  or  more  of  the  fol¬ 
lowing  flags  may  be  specified  as  described  above: 


COlOT=vaiue 


"  command=  ua/tic" 


devlce=w/«e 


fi.ll=value 


model=value 


When  used  as  a  flag  for  the  Hewlett-Packard  plotters,  it  specifies 
black-and-white  plots  {value  is  bw)  or  color  plots  {value  is 
color).  Default  is  color. 

When  used  as  a  flag  for  the  Hewlett-Packard  plotters,  it  specifies 
black-and-white  displays  {value  is  bw),  or  for  displays  that  sup¬ 
port  only  16  colors  {value  is  colorQ),  or  for  displays  that  sup¬ 
port  256  colors  {value  is  color). 

Specifies  disposition  of  the  graphics  driver  output  file  for  an 
Imagen  laser  printer.  The  entire  flag  must  be  enclosed  in  double 
quotation  marks  as  shown  since  the  value  field  may  contain 
blanks.  Typically,  the  value  field  is  a  print  command  giving  the 
disposition  of  the  output;  the  file  name  is  specified  with  a  %s 
which  the  ADAS  programs  replace  with  the  actual  file  name  at 
execution  time.  For  example: 

"command=prlnt/que=laser2/delete  %s" 

Specifics  an  input  device  port  number  for  a  Tektronix  worksta¬ 
tion.  Value  is  set  to  the  integer  number  of  the  input  port 
(default  is  0). 

Specifies  nonfilled  nodes  on  plots  {value  is  off)  or  filled  nodes 
on  plots  {value  is  on).  The  default  value  is  off.  NOTE:  If  this 
option  is  provided  at  your  site,  it  should  be  used  with  caution, 
since  node  filling  wears  out  plotter  pens  quickly  and  greatly 
increases  the  time  it  takes  to  generate  a  plot. 

Specifies  a  graphics  device  model.  Value  may  be  set  to 

10  for  a  Raster  Technologies  Model  1/10  (default  for  a  Raster 

Technologies  device) 

40  for  a  Raster  Technologies  Model  1/40  or  1/60 

4107  for  a  Tektronix  Model  4107  (default  for  a  Tektronix  device) 

or  4207 

4113  for  a  Tektronix  Model  4113  or  4115 
4125  for  a  Tektronix  Model  4125 
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resolutlon=i'a/Me  Specifies  pixels  per  inch  resolution  for  an  Imagen  laser  printer. 

Default  is  240  pixels/inch. 

Zype=vnlue  Specifies  a  device  type.  Value  may  be  set  ro 

7220  for  a  Hewlett-Packard  Model  7220-C  plotter 

7475  for  a  Hewlett-Packard  Model  7475  plotter 

7550  for  a  Hewlett-Packard  Model  7550  plotter 

7585  for  a  Hewlett-Packard  Model  7.585-B  plotter  (default  for  a 

Hewlett-Packard  plotter) 

standard  for  a  Mouse  Systems  Model  M-1  mouse  (default  for  a 
mouse) 

sumraamouse  for  a  Summagraphics  Summaivlouse 
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TROUBLESHOOTING  THE  INSTALLATION  PROCESS 


1.  -\DAS  Cannot  Initialize  Graphics  Device 

Check  fiie  graphtcs.dat  co  make  sure  there  is  a  device  b^/  that  aarae.  Make  sure  the  line 
name  is  'lorrect.  die  input  and^itput  types  are  valid,  and  that  device  flags  are  set 
correctly.  Make  sure  the  device  name  to  port  associations  and  baud  rates  are  correct  in 
the  second  half  of  the  file. 

If  there  are  no  identifiable  problems  in  graphtcs.dat.  check  the  terminal  line  and  make 
sure  it  has  read/write  protection.  If  the  graphics  device  is  a  terminal  emulator  ifor 
example,  the  Raster  Technologies  Model  1/10  can  emulate  a  VT-100  terminal),  make 
sure  it  is  cabled  correctly  by  trying  to  log  in  using  the  graphics  device  as  a  terminal. 


2.  ADAS  Monitor  Generates  An  Error 

If  the  error  message  reads 

ADAS  monitor  not  running.  See  your  system  manager. 

activate  the  monitor  as  [system]  by  entering  the  command 

$  @adas : [dlst .bln] run_monltor 

If  the  error  message  reads 

ADAS  monitor  error.  See  your  system  manager. 

you  must  stop  the  monitor  that  is  running,  then  reactivate  the  monitor  by  entering  the 
command 

$  @adas : [dlst . bln] run  monitor 


3.  Licensed  Simultaneous  ADAS  Use  Exceeded 

If  this  message  appears,  and  the  number  of  active  workstations  does  not  exceed  the 
number  specified  in  your  license,  you  must  stop  the  monitor  that  is  running,  then  reac¬ 
tivate  the  monitor  by  entering  the  command 

$  @adas :  [dlst . bln] run  monitor 
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4.  Mouse  Will  Not  Track  Or  Tracks  Incorrectly 

Try  powering  down  die  mouse  and  tiien  ohecic  die  connections.  Power  >  iie  mouse  oacic 
up  again  and  recalibrate.  If  you  are  using  a  Tektronix  device,  malte  '-ure  the  device 
flag  is  set  correctly  in  tile  gravhtcs.dat. 


5.  Other  Communication-Related  Problems 

Check  device  speeds  and  switch  settings:  check  the  cabling  between  the  mouse  or  lata 
tablet  and  the  graphics  device. 
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